PATENT 

EXPRESS MAIL NO. EV328618216US 



SYSTEM AND METHOD FOR THE AUTOMATED BROKERAGE 
OF FINANCIAL INSTRUMENTS 

Field of the Invention: 

The present invention relates to an automated electronic system 
for processing orders from investors for transactions of financial 
instruments and supplying financial account information to investors. 

5 

Background and Summary of the Invention: 

In the present day, investors are discovering that computers 
and, in particular, computer networks such as the Internet, are a 
particularly useful tool for managing and tracking their financial 

10 investment portfolio. Whether it is an individual investor seeking 
to occasionally buy or sell stocks, bonds, or other financial 
instruments; a day trader conducting numerous such transactions each 
day; or a professional investor such as a licensed broker who manages 
the financial portfolios of numerous clients; access via a computer 

15 network to financial markets to conduct these transactions is now and 
increasingly more so in the future an important channel for execution 
of this business. 

Thus, a need in the art has developed for an infrastructure 
that both supports access to the financial markets and provides fast 
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and efficient management of those transactions. In previous systems 
known to the inventors herein, such infrastructure as adopted and 
used in the prior art took on a client -server model such as that 
shown in Figure 1 . 

5 As shown in Figure 1, a trading company maintains a system 100 

that includes a back office mainframe computer 102 on which customer 
account data is stored. This customer account data generally 
includes personal information about each customer (e.g., name, 
address, etc.), the investment positions of each customer (e.g., what 

10 stocks that customer owns) , the value of those positions, and any 
other pertinent account information. To provide access to this 
account information, one or more web servers 104 are provided to 
allow a customer 108 to access the account information in the 
mainframe 102 via a computer network 106. Business logic that is 

15 resident on either or both of the web servers 104 and the mainframe 

102 operates to process activity requests from a customer such as (1) 
buying/selling financial instruments on a trading market 114 through 
a gateway 116 that formats the order requests in accordance with the 
market specifications and (2) getting current quote data for 

20 financial instruments from a quote vendor 112 . For a system 100 that 
experiences high customer traffic, redundant web servers are placed 
behind a load balancer 110 in order to alleviate any potential delays 
due to bottlenecks. Incoming activity requests from the customer 108 
are distributed by the load balancer 110 to an available web server 

25 104. 

However, as electronic trading of financial instruments has 
grown more popular, the demands placed on the system of Figure 1 have 
also increased. In handling this increased demand, the inventors 
herein have found that such a system is not easily scalable to 

30 accommodate high traffic volume. The approach of merely adding new 
web servers is only a partial solution to the problem for many 
reasons not the least of which is the cost required to provide each 
new "intelligent" web server and the problems inherent in the 
distributed logic working well between the increasing number of 

35 elements in the network. Recognizing the drawbacks of the prior art 
system structure and its inherent limitations, the inventors herein 
have developed a radical new approach for the design of the 
infrastructure for an automated financial instrument brokerage 
system. 

40 According to one aspect of the preferred embodiment of the , 

present invention, the inventors herein have abstracted the system' s 
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activity request processing business logic onto an intermediate layer 
that interfaces front end web servers with backend accounting 
databases, quote vendors, and trading market interfaces. This design 
effectively "gathers" the logic together into a single intermediate 
5 layer and removes it from the front end and back end layers . Such 

abstraction greatly improves the system' s flexibility to accommodate 
modifications in the backend of the system (e.g., a new accounting 
database, a new quote vendor, or a new trading market interface) or 
modifications in the front end of the system (e.g., modifications to 

10 the customer interfaces or the addition of new types of customer 
interfaces such as an interface to wireless devices such as cell 
phones or personal digital assistants (PDAs)). Accordingly, the 
intermediate "layer" or tier of business logic can remain unchanged 
or largely unchanged when such modifications occur. 

15 According to another aspect of the preferred embodiment of the 

invention, within the intermediate layer, various tasks of the 
business logic can be segmented to separate dedicated servers to 
provide further scalability and flexibility. For example, logic for 
processing order activity requests can be placed on one or more 

20 dedicated order servers . Logic for obtaining customer account data 
from a backend accounting database can be placed on one or more 
dedicated customer account servers . Logic for obtaining quote data 
can be placed on one or more dedicated quote servers . This 
separation of processing tasks onto separate dedicated servers on the 

25 basis of processing type, task or function improves the scalability 
of the system because if any particular server (e.g., the order 
server, the customer account server, and/or the quote server) becomes 
bogged down with traffic, an additional redundant server of that 
particular type can be added to the system for increased processing 

30 capabilities. Further, modifications to logic can be more easily 

implemented due to such segmentation as the logic is isolated on the 
corresponding dedicated server. 

According to another aspect of the preferred embodiment of the 
present invention, the intermediate layer servers preferably 

35 communicate with each other and with the front end layer via TCP/IP 
communication protocol, which accommodates the front end layer and 
intermediate layer being physically remote from each other and the 
various intermediate layer servers being physically remote from each 
other. 

40 According to another aspect of the preferred embodiment of the 

present invention, a plurality of redundant servers are preferably 
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implemented in the intermediate layer and a load balancer is 
preferably used to interface the redundant servers with the front 
end. The load balancer can also be used to interface the redundant 
servers with the other server types in the intermediate layer. For 
5 example, a load balancer can interface a plurality of redundant order 
servers with the front end. Preferably, a load balancer is used with 
a bank of redundant servers for each intermediate layer server type 
to distribute incoming activity requests among the redundant servers 
in a balanced manner, thereby greatly decreasing the processing delay 

10 for activity requests by eliminating processing bottlenecks. With 

such a configuration, when additional processing capability is needed 
for a particular type of processing (e.g., if there is congestion in 
the bank of redundant order servers) , one only needs to add a new 
redundant server of that type to the system and register that new 

15 redundant server with the load balancer for that server group. 

According to yet another aspect of the preferred embodiment of 
the present invention, data caching is preferably utilized in the 
intermediate layer servers to reduce the need for data transfers 
between the intermediate layer and the backend layer. For example, 

20 resident memory, preferably application- in-memory cache, on a 

customer account server can be used to store customer account data 
that has been recently retrieved from the backend accounting 
database. When an activity request is received by that customer 
account server that would utilize customer account data that is 

25 stored in the cache, the customer account server, in accordance with 
predetermined usage rules, can process that activity request in 
^ accordance with the cached data, thereby alleviating the need for a 
data transfer from the backend database. Such data caching provides 
a substantial increase in the speed of processing an activity 

30 request. Further, such data caching can also preferably be used in 
connection with the quote data that the quote server receives from a 
quote vendor . 

According to yet another aspect of the preferred embodiment of 
the present invention, the intermediate layer can process activity 

35 requests generated by the front end layer independently of the 

customer interface from which the activity request originated (e.g., 
for activity requests originating from a web site, from a wireless 
device, or from a touchtone telephone) through the use of a common 
interface that formats activity requests from any of the customer 

40 interfaces in the same manner. 
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According to yet another aspect of the preferred embodiment of 
the present invention, quote data can preferably be obtained from 
multiple quote vendors in a manner transparent to various services in 
the system, despite potential formatting differences in the quote 
data from the multiple vendors, because the quote server is 
preferably configured to convert all quote data into a common data 
format for internal system wide use, regardless of its source. 

According to yet another aspect of the preferred embodiment of 
the present invention, migration from an old backoff ice accounting 
database system to a new backoff ice accounting database system is 
facilitated by a "three day system" wherein interaction with the old 
and new backoffice databases proceeds according to a specialized 
protocol for the first three days of the migration. 

These and other features and advantages of the present 
invention will be in part apparent and in part pointed out in the 
following description and referenced figures. 

Brief Description of the Drawings : 

Figure 1 illustrates a prior art system for processing 
financial instrument transactions; 

Figure 2 illustrates a basic configuration for a preferred 
system of the present invention; 

Figure 3 illustrates another configuration for a preferred 
system of the present invention; 

Figure 4 illustrates the preferred system' s use of a common COM 
interface for the front end layer; 

Figure 5 illustrates a preferred processing flow for handling 
order activity requests; 

Figure 6 illustrates a preferred processing flow for handling 
quote activity requests ; 

Figure 7 illustrates a preferred processing flow for handling 
customer account activity requests; 

Figures 8 (a) - (g) illustrate various screenshots for a preferred 
front end web site customer interface; 

Figures 9 (a) - (n) illustrate various screenshots for a preferred 
front end wireless device customer interface; 

Figure 10 illustrates a screenshot for a preferred front end 
Windows trading application customer interface; 

Figure 11 illustrates a screenshot for a preferred front end 
Java trading application customer interface; 
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Figures 12 (a) - (c) illustrate screenshots for various preferred 
administrator interfaces for controlling the content of the trading 
admin database; - 

Figure 13 is a preferred table diagram for the customers 
5 database ; 

Figures 14(a) and (b) are preferred table diagrams for the 
orders database; 

Figures 15(a) and (b) are preferred table diagrams for the 
trading admin database; 
10 Figures 16 (a) - (c) are preferred screenshots for various 

approval desk interfaces ; 

Figure 17 illustrates the flexibility of the preferred system 
of the present invention for handling backend changes ; 

Figure 18 illustrates an embodiment of the invention wherein 
15 geographical site redundancy is provided; and 

Figures 19 (a) -(f) illustrate preferred interfaces for 
controlling the selection of quote vendors.' 

Detailed Description of the Preferred Embodiments : 

20 Figure 2 illustrates a basic configuration for a preferred 

system 150 of the present invention. The system 150 includes a front 
end layer 152, an intermediate layer 154, and a back end layer 156. 

The front end layer 152 acts an interface between users such as 
customers or brokers (preferably via a computer network such as the 

25 Internet) and the intermediate layer 154. A web server 158 can 

provide such an interface. Through the web server 158, a user can 
access a web site associated with the system 150 to initiate activity 
requests for the system 150. Activity requests can be any action 
requested by a user that pertains to a capability of the system. 

30 Examples of activity requests include, but are not limited to, an 

order request to buy or sell a financial instrument, a modification 
request to modify an order to buy/sell a financial instrument, a 
request to view the portfolio for a given customer account, and a 
request to view recent trade history for a given customer account . 

35 These and other activity requests supported by the preferred 

embodiment will be discussed further below. Also, it is worth noting 
that the term "financial instrument" is used in accordance with its 
ordinary meaning in the art to mean instruments that can be traded on 
a financial market or through an electronic order matching facility 

40 such as ECN, and includes, but is not limited to, items such as 

stocks, options, mutual funds, futures, securities futures, and the 
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like. The term "financial instrument" does not include checks or 
money orders . 

The front end layer preferably communicates with the 
intermediate layer through a component object model (COM) interface 
5 188 that is preferably resident on each of the front end servers. 

The COM interface 188 preferably comprises an OrderRules , dll 177, an 
OrderClient.dll 178, a WBOClient.dll 180, a WBOCalculations.dll 181, 
a QuoteClient.dll 182, and an ODBC 184. Additional details about 
these COM interfaces will be described below. 

10 The OrderRules COM object 177 obtains trading restriction data 

from the trading administration database described below and 
validates order activity requests against these restrictions. The 
OrderClient COM object 178 provides information needed by an order 
server 160 to process order activity requests. The WBOClient object 

15 18 0 provides information for obtaining appropriate customer account 
data from the customer account server 162. The WBOCalculations COM 
object 181 performs various calculations on the customer account data 
obtained through the WBOClient object 180. However, it should be 
noted that the functionality of the WBOCalculations object can be 

20 incorporated into the WBOClient object if desired. The QuoteClient 
object 182 provides information for obtaining appropriate quote data 
from the quote server 164. The ODBC object 184 provides information 
for interacting with the SQL database schema 166. 

The intermediate layer 154 preferably comprises an order server 

25 16 0, a customer account server 162, a quote server 164, and an SQL 
database schema 166. 

The order server 16 0 receives data from the OrderClient object 
178 and uses this data to process an order related to a financial 
instrument. In carrying out this processing, the order server 

30 preferably interacts with the other intermediate layer servers as set 
forth below. When an order is ready to be sent to the trading 
market, the order server prepares an order message for transmission 
to the order management system 168 from which it can be acted on by 
various stock exchanges /market centers 174. 

35 The customer account server 162 receives data from the 

WBOClient object 18 0 and uses this data to obtain the appropriate 
customer account information either from its own cache memory or from 
a back office accounting database system 170. In the preferred 
embodiment wherein at least one web server 158 is present in the 

40 front end layer 152 to provide access for customers to the system 150 
through a web site, the customer account server can be characterized 
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as a web-to-back office (WBO) server because it acts as a gateway 
between the customer using the website and the back office account 
information. In further discussions herein, the customer account 
server 162 will be referred to as a WBO server. However, it should 
5 be noted that the customer account server is not limited to being 

connected at the front end to web applications. Front end access to 
the customer account server can occur through any known technique of 
remote data access, including but not limited to LANs, VPNs, 
dedicated Tl lines, and the like. 

10 The quote server 164 receives data from the QuoteClient object 

182 and uses this data to obtain appropriate quote information from 
quote vendors 172 . This quote information is information relating to 
the pricing of financial instruments, examples of which are set forth 
below. For example, the quote server can act on a received 

15 QuoteClient activity request to obtain the current price for shares 
of IBM stock. 

The SQL database schema 166 receives activity requests from 
ODBC 184. The schema 166 supports various databases used by other 
intermediate layer servers when processing activity requests, as will 

20 be explained further herein. Preferably, the databases supported by 
database schema 166 include separate databases for orders (orders 
database 178) , trading administration (trading admin database 180) , 
and customers (customers database 182) . 

The back end layer 156 preferably comprises an order management 

25 system 168 that takes orders from the order server and places those 
orders on the trading market 174, a back office accounting database 
system 170 that stores customer account information, and an interface 
172 for receiving quote data from a quote vendor. Clearing services 
176 provide post trade functionality such as providing the settlement 

30 of trades and the movement of money between parties in the market . 

The scalability and flexibility of the preferred embodiment of 
the present invention is illustrated with Figure 3. In connection 
with the front end layer 152, the use of a common COM interface 188 
supports the use of multiple heterogeneous customer interfaces. For 

35 example, the preferred embodiment preferably supports a customer 

interface through a web site, wherein the web site is supported by a 
plurality of web servers 158. Also, a customer interface through 
touchtone telephones, including but not limited to voice recognition 
applications, can be supported through IVR touchtone servers 190. 

40 Further, customers can access the system 150 through a wireless 

device such as a cell phone, pager, personal digital assistant (PDA) , 
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and the like through wireless (WAP) servers 192. Lastly, through 
applications installed and running on a customer's computer, a 
customer can interact with the system through Windows trading 
application server 194 and Java trading application servers 196. The 
5 Windows trading application servers 194 support ScottradeElite 

software, which is commercially available from the assignee of the 
present invention. The Java trading application servers 196 support 
Scottrader software, which is also commercially available from the 
assignee of the present invention. 

10 Because each of these heterogeneous customer interfaces 

interacts with the intermediate layer 154 through a common COM 
interface 188, the intermediate layer is not affected by 
modifications to the customer interfaces. Figure 4 illustrates the 
use of such a common COM interface 188 for a customer interface 

15 through a web site and a customer interface through a wireless 

device. From the perspective of the intermediate layer, there is no 
difference between activity requests emanating from the web site or 
the wireless device. Further, scalability to the front end can be 
easily provided without altering the intermediate layer through the 

20 use of parallel servers in the front end. Thus, if traffic through 

the web servers 158 is particularly heavy, a new redundant web server 
can be added to alleviate congestion. 

Although not shown in Figure 3, it should be understood that 
the front end layer servers preferably interact with the users 

25 through various networks (not shown) , security firewalls (not shown) , 
and load balancers (not shown) that arbitrate balanced access to the 
redundant servers. Such implementations at the front end are 
standard and known in the art, and do not form part of the present 
invention. 

30 In the intermediate layer 154 of Figure 3, scalability is 

provided through the use of redundant order servers 160 in an order 
server bank 208, redundant WBO servers 162 in a WBO server bank 206, 
redundant quote servers 164 in a quote server bank 210, and clustered 
SQL databases for schema 166. 

35 To distribute incoming activity requests in a balanced manner 

to the various servers, it is preferred that load balancer 200 
connect the front end servers with the WBO server bank 162 . The load 
balancer 200 is configured to distribute access to the WBO servers 
162 according to a predetermined algorithm (e.g., round robin or any 

40 other known technique) in order to prevent server overload and 

maintain low activity request processing latency. In a preferred 

2196964 - 9 - 



\ 



embodiment, the load balancers distribute activity requests to 
awaiting servers according to a "best response time" criteria. Load 
balancers 202 and 204 preferably provide the same functionality in 
connection with order server bank 208 and quote server bank 210, 
5 respectively. Although in the preferred embodiment, separate load 

balancers are used for each server type in the intermediate layer, it 
should be understood that the same load balancer can be used to 
arbitrate access to both the WBO servers and the quote servers, or 
any other combination of the different intermediate layer server 

10 types. However, because the use of a single load balancer for 

servers of multiple processing types would introduce a- single point 
of failure to the system 150, the use of multiple load balancers, 
wherein each load balancer is assigned to a different server type is 
strongly preferred over the use of a single load balancer. Further, 

15 to more greatly ensure high availability of the intermediate layer 

server, redundant load balancers can be used with each server bank to 
take over for a load balancer in the event of a load balancer 
failure. A preferred load balancer for use with the system 150 is a 
CISCO CSS 11154. However, as should be understood, other load 

20 balancers can be used in the practice of the invention. . 

It is preferred that the load balancers maintain persistent 
load balanced connections with their redundant servers at the TCP/IP 
level . Through port monitoring wherein the load balancer checks the 
"heartbeat" of its connection to each redundant server, the load 

25 balancer will be able to detect whenever a server is unavailable. 
When the load balancer tests its TCP/IP port connection with each 
server to which it is connected, if no response is heard from the 
server to a "ping" after a predetermined amount of time has passed 
(preferably around 3 seconds) , the load balancer will remove that 

30 server's address from its list of available servers. Thus,- the load 
balancer can prevent incoming activity requests from being 
distributed to an unavailable server. 

The processing flow for handling various activity requests will 
now be described. 

35 Figure 5 illustrates the processing flow for handling customer 

account activity requests. A customer account activity request 
occurs when a requestor seeks to obtain information about a 
particular customer account. In the example of Figure 5, the 
requestor is a user at the front end layer, but it should be 

40 understood that other requestors are possible in the system such as 
an order server seeking to process an order activity request . 
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In Figure 5, at step 1000, the user initiates a request for 
some type of customer account data (e.g., one or more of the 
customer's positions, balance, recent trades, etc.). At step 1002, a 
WBOClient object 178 is communicated to the intermediate layer 154 
5 where it is load balanced (step 1004) and passed to an available WBO 
server 162. 

The WBO server 162 then checks its cache for "fresh" customer 
account data pertinent to the activity request (step 1006) , which 
will be explained in greater detail below. If pertinent cached data 

10 is found at step 1006, then at step 1008, the WBO server determines 
•whether that cached data is to be used. This determination is made 
according to one or more usage rules, as will be explained in greater 
detail below. If either step 1006 or step 1008 results in a negative 
determination, the WBO server will query the backoff ice accounting 

15 database system 170 for the pertinent customer account data. It is 
preferred that the WBO server also query the orders database 178 and 
customers database 182 for any pertinent customer account information 
that would not be found in the backoffice accounting database system 
170. At step 1010, the WBO server gets the pertinent customer 

20 account data from either its cache or the backoffice and 
customers/orders databases as may be appropriate. 

Thereafter, at step 1012, WBO server calls performs any 
calculations that need to be performed on the customer account data 
to satisfy the customer account activity request, such as a 

25 calculation of unsettled balances or the number of day trades for 

that day. These calculations preferably provide the functionality of 
the WBOCalculations object. 

Upon the completion of step 1012, customer account data that is 
responsive to the customer account activity request is passed back to 

30 the WBOClient 178 through the load balancing step for subsequent 

display to the user at step 1014. The load balancer preferably keeps 
an internal flow table to keep track of data that needs to be routed 
to a specific server rather than an available server. 

Figure 6 illustrates the preferred processing flow for handling 

35 quote activity requests . A quote activity request occurs when a 

requestor seeks to obtain data related to pricing information about a 
particular financial instrument . In the example of Figure 6 , the 
requestor is a user, but it should be understood that other 
requestors are possible, such as an order server seeking to process 

40 an order activity request. 
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In Figure 6, at step 1030, the user initiates a request for a 
quote (e.g., a request to see the price at which IBM stock is 
trading). At step 1032, a QuoteClient object 180 is communicated to 
the intermediate layer 154 where it is load balanced (step 1034) and 
5 passed to an available quote server 164 . 

The quote server 164 then operates, at step 1036, to obtain the 
requested quote data either from its cache or from a quote vendor 
172, as will be explained in greater detail below. Once the quote 
server 164 obtains the requested quote data, this quote data is 

10 passed back to the QuoteClient object 180 through the load balancing 
step for subsequent display to the customer (step 1038) . 

Figure 7 illustrates the processing flow for handling order 
activity requests. An order activity request occurs when a requestor 
seeks to conduct a transaction associated with a financial instrument 

15 order. Requestors may be customers or brokers. Typical orders 
originate from user input through the front end (step 1100) . 

Thereafter, at the front end, the OrderRules object is called 
to validate the order activity request against restrictions stored in 
the trading administration database 180, as will be explained below 

20 (step 1102) . Then, if the order is valid (step 1104) , an OrderClient 
object is communicated to the intermediate layer (step 1106) . If the 
order is not valid, the remote front end user is notified and the 
process will await a new order activity request. 

The OrderClient object arriving at the intermediate layer is 

25 load balanced at step 1108. After load balancing, it arrives at an 
available order server, which in turn calls QuoteClient (step 1112) 
and calls WBOClient (step 1114) . QuoteClient is called to obtain 
appropriate pricing information from an available quote server about 
the financial instrument involved in the order activity request. The 

30 QuoteClient request issued by the order server will pass through load 
balancing at step 1116 to arrive at an available quote server at step 
1118 where the pertinent quote data will be obtained and returned to 
the order server (once again through a load balancing step) . 
WBOClient is called to obtain customer account data from an available 

35 WBO server that is pertinent to the order activity request. The 
WBOClient activity request issued by the order server will pass 
through load balancing at step 112 0 to arrive at an available WBO 
server at step 1122 where the appropriate customer account data will 
be obtained from either, all, or some combination of the backoff ice 

40 accounting database system, the customers database, the orders 

database, and the WBO server's own cached data. Thereafter, the 
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customer account data is passed back to the order server (after a 
return trip through a load balancing step) . 

At step 1124, the order server implements business logic to 
determine whether the received order activity request should be 
5 accepted. Acceptance is generally conditional on the quote data and 
customer account data revealing whether sufficient buying power 
exists in the customer's account for the order. This standard 
business logic is known in the art and will not be elaborated on 
herein . 

10 It is preferred that the order server at this step also include 

unique business logic wherein some order activity requests will be 
passed to an approval desk for human intervention by a broker through 
an approval desk interface that will be described below. If approved 
from the approval desk interface, the order activity request will 

15 proceed like other orders from step 1124. Preferred conditions for 
invoking the approval desk include forwarding an order activity 
request to the approval desk: (1) if the SecurityMaster for the 
symbol is not set up correctly or is missing routing codes, (2) if a 
market order is being cancelled, (3) if an options order includes 

20 over 200 contracts, (4) if an equity order includes over 50,000 
shares, with the share price being at least $1, (5) if an equity 
order includes over 200,000 shares, with the share price being under 
$1, (6) if selling an option call to open, (7) if selling short while 
the market is closed, and (8) if it is near the market's closing time 

25 and the order might not reach the exchange floor in sufficient time 
prior to closing. As should be understood, these conditions may be 
altered by a practitioner of the invention to meet one's specific 
business needs. 

If step 1124 finds the order to be unacceptable, then, at step 
30 1126, the ODBC object is preferably called to write the order attempt 
into the orders database, thereby creating audit trail information. 

If step 1124 finds the order to be acceptable, then at step 
1128, the ODBC object is preferably called as at step 1126. 
Thereafter, at step 1130, FixOrderServer is called by the order 
35 server to format the order activity request as a FIX packet to be 
sent to the order management system. At step 1132, the order 
management system forwards the FIX packet created from the order 
activity request to the appropriate financial market, such as the 
Nasdaq or NYSE. After acknowledgement of the order transmission is 
40 received, the order server calls the Notif icationSwitchClient object 
to create and send multicast packets to inform interested 
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applications of the order transmission. Preferably, this multicast 
is sent to the WBO servers so that that its cache can be updated and 
to any front end applications that support real time updates on 
trades such as the Java trading application and the Windows trading 
5 application. 

When the market informs the order management system of the 
order's execution, the Notif icationSwitchClient object is preferably 
called once again by the order server to multicast notice of the 
execution to interested applications. Preferably, this multicast is 
10 sent to the WBO servers so that that its cache can be updated and to 
any front end applications that support real time updates on trades 
such as the Java trading application and the Windows trading 
application. 

It is also worth noting that the automated brokerage system of 
15 the preferred embodiment supports entry of orders through the 
backoff ice, wherein a broker directly enters an order in the 
backoff ice accounting database system. Such orders are preferably 
communicated directly from the backoff ice accounting database 17 0 to 
the order management system at step 1132, as shown in Figure 7. 

20 

I . FRONT END LAYER : 

With reference to Figure 3, the system's front end layer 152 
preferably supports a plurality of heterogeneous applications that 
generate activity requests in response to user input. These 

25 heterogeneous front end applications can be thought of as delivery- 
channels from which activity requests are delivered to the 
intermediate layer 154 . From the perspective of the intermediate 
layer 154, the heterogeneous nature of the various customer 
interfaces is immaterial due to the commonality of the COM interface 

30 188. 

Examples of heterogeneous customer applications supported by 
the preferred system 150 include website applications provided by web 
servers 158, touchtone telephone applications provided through IVR 
touchtone servers 190, wireless device applications from cell phones, 

35 pagers, PDAs, and the like through wireless (WAP) servers 192, 
desktop computer application access through Windows trading 
application servers 194 and Java trading application servers 196. A 
Dell 1550, dual 1133 MHz server with 1 GB of RAM and mirrored 18 GB 
drives is the preferred hardware for the front end servers. 

40 Figures 8(a) through 8(g) illustrate various screenshots for a 

preferred website customer interface supported by web servers 158. 
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Figure 8 (a) illustrates a preferred home page for the trading web 
site. Figure 8(b) illustrates a preferred page for displaying 
detailed customer account information. Figure 8(c) illustrates a 
preferred page for displaying open orders and trade executions. 
5 Figure 8 (d) illustrates a preferred page for displaying a customer' s 
positions. Figure 8(e) illustrates a preferred page for an initial 
step of entering order activity requests. Figure 8(f) illustrates a 
preferred page for a second step of entering order activity requests, 
including confirmation/verification. Figure 8(g) illustrates a 

10 preferred page illustrating a third step in entering order activity 
requests, including an order identification. 

A customer interface application for the IVR touchtone servers 
190 would occur through a touchtone telephone from which a customer 
can initiate activity requests and interact with the server system 

15 via automated systems known in the art. Such automated systems would 
then interact with the intermediate layer via the COM interface 188. 

Figures 9(a) through 9 (n) illustrate various screenshots for a 
preferred wireless device customer interface supported by wireless 
servers 192, wherein the wireless device is a cell phone. Figure 

20 9(a) illustrates a preferred main menu displayed by the wireless 
device. Figure 9(b) illustrates a screen listing market indices. 
Figure 9(c) illustrates a preferred screen for an initial step of 
entering order activity requests. Figure 9(d) illustrates a 
preferred screen for a second step of entering order activity 

25 requests, including confirmation/verification. Figure 9(e) 

illustrates a preferred screen for a third step of entering order 
activity requests, including an order identification. Figure 9(f) 
illustrates a preferred screen for listing trade executions. Figure 
9(g) illustrates a preferred screen for login. Figure 9(h) 

30 illustrates a preferred screen for listing account balances. Figure 
9(i) illustrates a preferred screen for listing open orders. Figure 
9(j) illustrates another preferred screen for order entry. Figure 
9(k) illustrates a preferred screen for listing a customer's 
positions. Figure 9(1) illustrates a preferred screen for displaying 

35 quotes. Figure 9 (m) illustrates a preferred screen for quote entry. 
Figure 9 (n) illustrates a preferred welcome screen. 

Figure 10 illustrates a screenshot for a preferred Windows 
desktop application customer interface supported by the Windows 
trading application servers 194. The screenshot of Figure 10 is from 

40 ScottradeElite software that can be installed on a PC. The 
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ScottradeElite software is commercially available from the assignee 
of the present invention. 

Figure 11 illustrates a screenshot of a preferred Java-based 
desktop application customer interface supported by the Java trading 
5 application servers 196. The screenshot of Figure 11 is from 

Scottrader software that can be installed on a PC. The Scottrader 
software is commercially available from the assignee of the present 
invention. 

10 II. INTERMEDIATE LAYER: 

A . Order Service 

The order service preferably accepts, transmits and validates 
activity requests that are orders to buy/sell financial instruments. 

15 The order servers 16 0 receive orders from the various front end 
delivery channels (e.g., through the web servers 158), request 
information from the WBO service to use in validating the order (s) 
(to obtain data such as the customer's money balances, any 
restrictions on the customer's account, etc.), request information 

20 from the quotes service (to use in pricing and validating orders) , 

and from the SQL database server 166 (to determine if the particular 
financial instrument that is the subject of the order activity 
request is eligible to trade) , if the delivery channel is enabled for 
trading, and so on. Figure 7 illustrates this process. Preferred 

25 hardware for the order server is a Dell 1550, dual 1133 MHz server 
with 1 GB of RAM and mirrored 18 GB drives operating with Windows 
2000 server. 

If an order is rejected, the orders service operates to store 
that order in the orders database 178 along with the reason for the 

30 rejection, audit trail information, and so on. If the order is 

accepted, the orders service also stores the order and audit trail 
information in the Orders database 178. Further, the orders service 
then passes the order on to the Order Management System (OMS) 168 for 
further processing (see below) . As noted above, multiple order 

35 servers 160 preferably exist behind a TCP/IP load balancer 202 to 

allow for the delivery channel application to fail over seamlessly if 
any particular order server should fail. 

(i) OrderClient 

40 OrderServer, which is a dedicated application, preferably a 

Windows C++ application, and OrderClient use a size-delimitated 
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protocol where each X bytes contain a specific piece of data. This 

format is required by OrderServer . 

As noted above, OrderClient 178 is a COM object that is 

preferably created in the language C++, but can be created under any 
5 language that supports COM. The use of a COM object allows for use 

of the same object on many different trading platforms while using a 

common code set for handling orders. 

OrderClient 178 takes generic order information (account 

number, buy/sell stock, shares, limit price, qualifiers, etc) and 
10 creates a packet. OrderClient then sends this packet over a TCP/IP 

socket to an order server 160. The OrderServer program resident on 

the order server 160 then formats the packet using a protocol as 

explained below. It is preferred that OrderClient and OrderServer 

communicate with each other over a TCP/IP socket. OrderServer 
15 preferably listens on port 5665 of the order server 160 for 

connections. 

OrderServer preferably (1) accepts socket connections from 
OrderClient, (2) parses the received packets into data structures 
that represent generic orders, (3) processes the order, (4) sends a 

20 response back over the same socket to the OrderClient that sent the 
packets, and (5) then disconnects from the socket. 

OrderServer preferably processes the order by validating the 
order against the business rules specific to the client's account. 
To do this, OrderServer needs customer account data, and to obtain • - 

25 such data, WBOClient 180 is also resident on OrderServer. Using 

WBOClient 180 (which will be explained below) , OrderServer is able to 
obtain the customer account data needed to validate the order 
activity request in accordance with business rules. OrderServer also 
preferably stores the order in the orders database 178. Further 

30 still, OrderServer sends the order to the order switch 168 over a 
socket, using FixOrderServer . 

FixOrderServer takes general order information, creates a 
FIX packet, and sends the packet over a socket to the order switch 
168. A FIX packet is a packet formatted in accordance with the FIX 

35 protocol, which is a well-known industry standard for communicating 

financial instrument orders on a trading market. FixOrderServer also 
receives the status updates for that order and any executions that 
occur. FixOrderServer stores the received data in the orders 
database 178, and notifies any waiting client applications that the 

40 updates occurred. 
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OrderServer then receives the response back from 
FixOrderServer , updates the orders database with the appropriate 
state and messages, and then sends a response back to OrderClient. 

Further, when any activity occurs in a customer's account, 
5 FixOrderServer sends a multicast packet stating what specifically 
just happened in the account. Any server listening for the 
multicasts can receive this alert and take appropriate action. For 
example, the WBO server 162 may be interested in the action so it can 
update its cache memory usage rules . FixOrderServer preferably sends 
10 this multicast using Notif icationSwitchClient . 

Notif icationSwitchClient is a COM object used to send 
multicasts over the TCP/IP network to notify interested applications 
of specific activity in a client's account. Notif icationSwitchClient 
sends things like orders placed, cancels placed, modifies placed, 
15 executions received, order rejects, order status changes and cancels 
processed. Any application listening for these multicasts can 
receive them and handle the updates appropriately. 

OrderClient, once this process has run,, interprets the 
results received from OrderServer, and determines if the order was 
20 accepted or rejected. Thereafter, OrderClient passes this 

information back to the client application for display to the 
customer. 

The preferred communication -protocol for packets in this 
process is such that the packets contain a Header followed by a 
25 ReHeader, followed by appropriate Request data, and finally, followed 
by a Trailer. 

The Header contains the following fields with their 
corresponding length: 

30 Header - 10 bytes 

MessageLength - 6 bytes 

Request - 10 bytes 

Max Reply Size - 6 bytes 

User Reference - 20 bytes 
35 Account Number - 8 bytes 

The ReHeader contains the following fields with their 
corresponding length : 
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Number of Records - 6 bytes 
Size of each Record - 6 bytes 

The Request section will vary depending on the request type, 
indicated by the Request field of the Header. The Request field can 
have the following type values: 



#def ine 


PACKET^ 


_HEADER_ 


ORDER ' 


"ORDER" 


#def ine 


PACKET_ 


_HEADER_ 


MODIFY 


"MODIFY" 


#def ine 


PACKET_ 


_HEADER_ 


CANCEL 


"CANCEL" 


#def ine 


PACKET_ 


_HEADER_ 


APPROVEJDRDER 


"APPROVE" 


#def ine 


PACKET_ 


_HEADER_ 


_REJECT_ORDER 


"REJECT" 


#def ine 


PACKET_ 


_HEADER_ 


_MANUAL__AP PROVED 


"MANAPPROVE 


#def ine 


PACKET_ 


_HEADER_ 


_MANUAL__REJECTED 


"MANREJECT" 


#def ine 


PACKET_ 


_HEADER_ 


VAL I DATE_ORDER 


" V AL_0 R D E R " 


#def ine 


PACKET_ 


_HEADER_ 


_DELETE_ORDER 


"DELETE" 



The Request section will then have the appropriate data for 
each request type. 

"ORDER" or "VAL ORDER" 
Account = 8 bytes 
Action = 15 bytes 
Quantity = 14 bytes 
Symbol = 9 bytes 
TradeType = 12 bytes 
LimitPrice = 14 bytes 
StopPrice = 14 bytes 
TIF = 12 bytes 
Restrictions = 20 bytes 
TradingPeriod = 12 bytes 
Commission = 10 bytes 
IgnoreWarnings = 1 bytes 
Source = 10 bytes 
Clientlp = 20 bytes 
LocalHost = 20 bytes 
QueryString = 2 56 bytes 
Language = 3 bytes 
Blank = 125 bytes 
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"CANCEL" 
Account = 8 bytes 

WebTrackingNumber = 15 bytes 

IgnoreWarnings = 1 bytes 

5 Source = 10 bytes 

Clientlp = 20 bytes 

LocalHost = 20 bytes 

QueryString =256 bytes 

Language = 3 bytes 

10 Blank = 125 bytes 

"MODIFY" 1 
Account = 8 bytes 
Action = 12 bytes 

15 Quantity = 14 bytes 
Symbol = 6 bytes 
TradeType = 12 bytes 
LimitPrice = 14 bytes 
StopPrice = 14 bytes 

20 TIF = 12 bytes 

Restrictions = 20 bytes 
TradingPeriod = 12 bytes 
Commission = 10 bytes 
IgnoreWarnings = 1 bytes 

25 Source = 10 bytes 

Clientlp = 20 bytes 
LocalHost =20 bytes 
QueryString = 2 56 bytes 
WebTrackingNumber = 15 bytes 

30 AON = 1 bytes 

OriginalQuantity = 14 bytes 
Language = 3 bytes - 
Blank = 12 5 bytes 

35 "APPROVE" or "MAN APPROVE" 

WebTrackingNumber = 16 bytes 
Broker = 16 bytes 
Message = 500 bytes 
Blank = 12 8 bytes 
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"REJECT" or "MANREJECT" 

WebTrackingNumber = 16 bytes 
Broker = 16 byte 
Message = 500 byte 
Blank = 128 bytes 



"DELETE" 
WebTrackingNumber = 16 bytes 
Broker = 16 bytes 
Message = 500 bytes 
Blank = 128 bytes 

The Trailer section preferably contains the following: ^ 

End Of Message - 1 byte 

The response packet that OrderServer sends back to 
OrderClient is formatted according to the same protocol. However, 
with the response packet, the Request section is formatted as a 
response for the appropriate request type. 

For an order, modify or cancel request the data is formatted 

like: 



WebTrackingNumber = 2 0 bytes 
Ac count Type = 6 bytes 

Supported field values are.: 



// order types 
static char* S TR_MOD I FY 

static char* STR_CANCEL 

static char* STR_ORDER 

static char* STR_OPTION 

static char* STR_MODIFY_OPTION 

static char* STR CANCEL OPTION 



"MODIFY"; 
"CANCEL"; 
"ORDER"; 
"OPTION"; 
"MODIFY OPTION"; 
A CANCEL OPTION"; 
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// order actions 
static char* STR_BUY 

static char* STR_SELL 

static char* STR_SELL_SHORT 

static char* STR_BUY_TO_COVER 

static char* STR_BUY_TO_OPEN 

static char* STR_BUY__TO_CLOSE 

static char* STR_SELL_TO_OPEN 

static char* STR SELL TO CLOSE 



*BUY"; 

^SELL"; 

*SELL_SHORT"; 

x BUY_TO_COVER" ( 

*BUY_TO_OPEN"; 

*BUY_TO_CLOSE", 

*SELL_TO_OPEN", 

% SELL TO CLOSE' 



// account types 
static char* STR_CASH 

static char* STRJVLARGIN 

static char* STR SHORT 



A CASH"; 
* MARGIN" ; 
" SHORT "; 



// order TIF's 

static char* STR_DAY = "DAY"; 

static char* STR_GTC = "GTC"; 

static char* STR_FOK =• " FOK" ; 



// trade types 
static char* STR_MARKET 
static char* STR_LIMIT 
static char* STR_STOP 
static char* STR STOPLIMIT 



x MARKET" ; 
*LIMIT" ; 
x STOP"; 
^STOPLIMIT"; 



// restrictions 
static char* STR AON 



"AON"; 



// trading periods 
static char* STR_REGULAR_HOURS 

static char* STR_EXTENDED_HOURS 

static char* STR PREMARKET 



* REGULAR" ; 
x EXT_HOURS"; 
1 PREMARKET"; 



// source 

static char* STR_WEB = "WEB"; 

static char* STR_IVR = "IVR"; 

static char* STR_STREAMER = "STREAMER"; 
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static char* STR_WIRELESS 
static char* STR_APPROVAL 
static char* STR_ELITE 
static char* STR__WEB_OPTIMIZED 
static char* STR TAIWAN SOURCE 



"WIRELESS"; 

"APPROVAL"; 

"ELITE"; 

"WEB_OPT"; 

"TW"; 



// options 
static char* STR_PUT 

static char* STR_CALL 

static char* STR_ERROR 

static char* STR EMPTY 



X PUT"; 
"CALL"; 
"ERROR"; 



// 1 anguages 
static char* STR_LANGUAGE_ENGLISH 

static char* STR_LANGUAGE_TAIWAN 

The specifications for various tasks of OrderClient are as 

follows: 

Function: SendOrder 

SendOrder operates to send an order through the order routing 
system. SendOrder will return an array either containing warnings 
and errors for the order, or the web_tracking_number of the order if 
accepted. 

Case Errors and Warnings: A variable number of array elements, 
where each element is an array containing 2 elements: the first being 
a boolean value representing fatal errors with the order (FALSE would 
mean the error message is just a warning, and the order may be 
resubmitted if appropriate) , and the second value being the message 
for the error /warning. 

Case Success: An array consisting of 2 elements, the first 
being a BSTR representing the web_tracking_number of the order, and 
the second being a BSTR representing the account type the trade was 
placed in (CASH, MARGIN, or SHORT) 

Parameters [in] : 

BSTR account 
BSTR action 
BSTR quantity 



"US"; 
"TW"; 
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BSTR symbol 
BSTR tradeType 
BSTR limitPrice 
BSTR stopPrice 
BSTR tif 

BSTR restrictions 
BSTR tradingPeriod 
BSTR commission 
BOOL ignoreWarnings 
BSTR source 
BSTR clientlp 
BSTR queryString 

Parameters [out , retval J 

VARIANT* pRet 

15 Function: SendModify 

SendModify operates to send an modify order through the order 
routing system. SendModify Will return an array either containing 
warnings and errors for the order, or the web_tracking_number of the 
order if accepted. 

20 Case Errors and Warnings: A variable number of array elements, 

where each element is an array containing 2 elements : the first being 
a boolean value representing fatal errors with the order (FALSE would 
mean the error message is just a warning, and the order may be 
resubmitted if appropriate) , and the second value being the message 

25 for the error/warning. 

Case Success: An array consisting of 2 elements, the first 
being a BSTR representing the web_tracking_number of the order, and 
the second being a BSTR representing the account type the trade was 
■•' placed in (CASH, MARGIN, or SHORT) 

30 Parameters [in] : 

BSTR account 
BSTR action 
BSTR quantity 
BSTR symbol 
35 BSTR tradeType 

BSTR limitPrice 
BSTR stopPrice 



5 



10 
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BSTR tif 

BSTR restrictions 
BSTR tradingPeriod 
BSTR commission 
5 BOOL ignoreWarnings 

BSTR source 
BSTR clientlp 
BSTR queryString 
BSTR origWebTrackingNumber 

10 Parameters [out , retval] 

VARIANT* pRet 

Function: SendCancel 

SendCancel operates to send a cancel request through the order 
routing system. SendCancel will return an array either containing 
15 warnings and errors for the order, or the web_tracking_number of the 
order if accepted. 

Case Errors and Warnings: A variable number of array elements, 
where each element is an array containing 2 elements : the first being 
a boolean value representing fatal errors with the order (FALSE would 
20 mean the error message is just a warning, and the order may be 

resubmitted if appropriate) , and the second value being the message 
for the error /warning. 

Case Success: An array consisting of 2 elements, the first 
being a BSTR representing the web_tracking_number of the order, and 
25 the second being a BSTR representing the account type the original 
trade was placed in (CASH, MARGIN, or SHORT) . 

Parameters [in] 

BSTR account 
BSTR trackingNumber 
30 BOOL ignoreWarnings 

BSTR source 
BSTR clientlp 
BSTR queryString 

Parameters [out, retval] 
35 VARIANT* pRet 
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Function: SendApproveOrder 

SendApproveOrder operates to approve an order from the 
approval desk. The approval desk is part of the administration 
process where some orders are routed for "approval by a broker before 
5 being forwarded to the OMS . For example, large orders or short sells 
may be sent for review by a broker before the corresponding order is 
transmitted to an exchange. The broker, through the approval desk, 
may then approve or reject the order. 

The orders sent to the approval desk are preferably stored 
10 temporarily in the orders database and flagged to trigger the review 
process. It is preferred that orders rejected from the approval desk 
are written to the audit trail just as automatically rejected orders 
are . It is also preferred that orders approved from the approval 
desk are transmitted via FIX in the same manner as other orders. 

15 The approval desk may also server as a destination of "last 

resort" should the order servers be unable to transmit an order to 
the OMS, exchanges, and backoff ice. Once reaching the approval desk, 
an order can be manually dealt with if necessary, such as being 
phoned into an exchange. 

20 Figures 16 (a) - (c) illustrate preferred approval desk 

interfaces from which a person an approve/re ject orders. Figure 
16 (a) illustrates a preferred main page for the approval desk 
interface that lists orders awaiting approval. By clicking on an 
order, a person using the approval desk interface (who is preferably 

25 a broker) will be linked to a page with detailed options for handling 
the order. Figure 16(b) illustrates a preferred instance of such a 
detailed page. The page of Figure 16(b) preferably provides the 
broker with the information necessary to either approve, reject, 
delete, or pass over the. order. Figure 16(c) illustrates a history 

30 page for an order that displays audit trail information therefor. 

SendApproveOrder will attempt to send the order through to 
the backoffice and remove the order from *tbl_orders_pending' in the 
orders database 178 . If successful (meaning the order either went 
through to the OMS, or it got transferred to the approval desk) , 
35 SendApproveOrder returns a VARIANT cast as a BSTR with the value 

"SUCCESS". Otherwise, if the order could not be found/transferred to 
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approval desk/database error occurred/etc . . , then SendApproveOrder 
returns a value of "FAILED" . 

Parameters [in] : 

BSTR webTrackingNumber 
5 BSTR broker 

BSTR message 

Parameters [out, retval] 

VARIANT* pRet 

Function: SendRe j ectOrder 

10 SendRe j ectOrder operates to reject an order from the 

Approval desk. SendRe j ectOrder will attempt to reject an order that t 
is pending, meaning that it will remove it from * tbl_orders_pending' 
of the orders database 178, and notify the customer if necessary. If 
successful (meaning the order was successfully removed) , 

15 SendRe j ectOrder returns a VARIANT cast as a BSTR with the value 

"SUCCESS". Otherwise, if the order could not be found if a database 
error occurred/etc.., then SendRe j ectOrder returns a value of 
"FAILED" . 

Parameters [in] : 

20 BSTR webTrackingNumber 

BSTR broker 
BSTR message 

Parameters [out, retval] : 

VARIANT* pRet) ; 

25 Function: SendManualApproveOrder 

SendManualApproveOrder operates to manually approve an order 
from the approval desk. SendManualApproveOrder will attempt to 
update the system to reflect that an order has been manually entered 
into the backoff ice already. If successful (meaning the order was 
30 successfully removed) , SendManualApproveOrder returns a VARIANT cast 
as a BSTR with the value "SUCCESS". Otherwise, if the order could 
not be found/database error occurred/etc, then 
SendManualApproveOrder returns a value of "FAILED". 



2196964 



- 27 - 



Parameters [in] ; 

BSTR webTrackingNumber 
BSTR broker 
BSTR message 

5 Parameters [out, retval] 
VARIANT* pRet 

Function : SendManualRe j ectOrder 

SendManualRejectOrder operates to manually reject an order 
from the approval desk This will attempt to update our system to 

10 reflect an order has been rejected by the Manual entry desk for one 
reason or another. If successful (meaning the order was successfully 
removed), SendManualRejectOrder returns a VARIANT cast as a BSTR with 
the value "SUCCESS" . Otherwise, if the order could not be. 
found/database error occurred/etc.., then SendManualRejectOrder 

15 returns a value of "FAILED". 

Parameters [in] : 

BSTR webTrackingNumber 
BSTR broker 
BSTR message 

20 Parameters [out , ' retval] 

VARIANT* pRet) ; 

(il) OrderRules 

OrderRules is a COM object that is preferably resident on the 
25 front end servers . OrderRules operates to take generic order 

information and determine whether the order parameters are acceptable 
according to the business rules for the source from which the order 
came . 

Preferably, only order parameters are validated by OrderRules ,- 
30 anything specific to the customer account that is placing the order 
is disregarded (the order servers will handle this with business 
logic) . OrderRules validates things like: order quantity (to make 
sure it's a valid quantity for that stock/option), limit/stop price 
(to make sure they are within the allowed range) , symbol (to make 
35 sure it's a valid symbol that the financial institution allows 

trading of), qualifiers (to make sure it's a valid qualifier for the 
order type, etc.) . OrderRules does this by taking the order 
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parameters and processing them against the financial institution' s 
rules engine and checking database settings in the trading admin 
database 180 to make sure that the order meets the institution's 
acceptable criteria. To obtain the necessary data from the trading 
5 admin database 18 0, an ODBC request is used. 

The trading admin database's settings are preferably controlled 
through an administrator interface such as those shown in Figures 
12 (a) - (c) . 

The administrator interface of Figure 12 (a) allows an 

10 administrator to control settings in the trading admin database 

relative to a particular financial instrument symbol . Through the 
interface of Figure 12 (a) , control is provided over whether 
restrictions are placed on any of the following for the specified 
symbol: routing for orders, buy enablement, sell enablement, sell 

15 short enablement, buy to cover enablement, buy to open enablement, 
buy to close enablement, sell to open enablement, sell to close 
enablement, extended hours trading enablement, option chain 
enablement, minimum lot size specification, margin requirement 
setting, and whether to add a disallowed option root or symbol and 

20 corresponding type. 

The administrator interface of Figure 12 (b) provides 
administrative control over disallowed options. Preferably, the 
options are identified by symbol, type, and underlying security (if 
applicable) . Control over the options listed in Figure 12 (b) is 

25 provided through the "Add Disallowed Option Root or Symbol" field of 
Figure 12 (a) . 

The administrator interface of Figure 12 (c) provides 
administrative control over various other tasks, such as control of 
master trading for entries, modifies, and cancellations. Further, 
30 master control is provided for trading over the NYSE, Nasdaq, and 
AMEX. Further still, entry, modify, and cancellation control is 
provided for equities, options, extended hours, and the Scottrader 
application. Further, entry control for bulletin board trading is 
supported. 

35 The specifications for OrderRules are as follows: 

Function: CheckMasterTrading 

CheckMasterTrading operates to return a Boolean value on 
whether or not there are trading restrictions on MAS TER_TRAD I NG in 
the trading admin database 18 0 (see Figure 12 (c) for administrative 
40 control of MASTER__TRADING) . If no restrictions are found therein, 
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the function returns a true value. If there are restrictions, the 
function returns a false value. 

Parameters [in] : 

none 

Parameters [out, retval] : 
BOOL* pRet 

Function : CheckMasterModif ies 

CheckMasterModif ies operates to return a Boolean value on 
whether or not there are trading restrictions on MASTER_MODIFIES in 
the trading admin database 180 (see Figure 12 (c) for administrative 
control of MAS TER_MOD I F I E S ) . If no restrictions are found therein, 
the function returns a true value. If there are restrictions, the 
function returns a false value. 

Parameters [in] : 

none 

Parameters [out, retval] : 
BOOL* pRet 

Function: CheckMasterCancels 

CheckMaster Cancels operates to return a Boolean value on 
whether or not there are trading restrictions on MASTER_CANCELS in 
the trading_admin database 180 (see Figure 12 (c) for administrative 
control of MASTER_CANCELS ) . If there are no restrictions, the 
function returns a true value. If there are restrictions, the 
function returns a false value. 

Parameters [in] : 

none 

Parameters [out, retval] ; 
BOOL* pRet 

Function: CheckEquityTrading 

CheckEquityTrading operates to return a Boolean value on 
whether or not there are trading restrictions on EQUI TY_TRAD ING in 
the trading admin database 180 (see Figure 12 (c) for administrative 
control of EQUITY__TRADING) . If there are no restrictions, the 
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function returns a true value. If there are restrictions, the 
function returns a false value. 

Parameters [in] : 

none 

Parameters [out, retval] : 
BOOL* pRet 

Function : CheckEquityModif ies 

CheckEquityModif ies operates to return a Boolean value on 
whether or not there are trading restrictions on EQU I T Y_MOD I F I E S in 
the trading admin database 18 0 (see Figure 12 (c) for administrative 
control of EQUI T Y_M0D I F I E S ) . If there are no restrictions, the 
function returns a true value. If there are . restrictions , the 
function returns a false value. 

Parameters [in] : 

none 

Parameters [out, retval]: 
BOOL* pRet 

Function: CheckEquityCancels 

CheckEquityCancels operates to return a Boolean value on 
whether or not there are trading restrictions on EQUI TY_CANCELS in 
the trading admin database 180 (see Figure 12 (c) for administrative 
control of EQUITY_CANCELS) . If there are no restrictions, the 
function returns a true value. If there are restrictions, the 
function returns a false value. 

Parameters [in] : 

none 

Parameters [out, retval] : 
BOOL* pRet 

Function: CheckBBTrading 

CheckBBTrading operates to return a Boolean value on whether or 
not there are trading restrictions on BB_TRAD I NG in the trading admin 
database 180 (see Figure 12 (c) for administrative control of 
BB_TRAD I NG ) . If there are no restrictions, the function returns a 
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true value. If there are restrictions, the function returns a false 
value . 

Parameters [in] : 
none 

Parameters [out, retval] : 
BOOL* pRet 

Function: CheckBBModif ies 

CheckBBModif ies operates to return a Boolean value on whether 
or not there are trading restrictions on BBJVIODIFIES in the trading 
admin database 180 (see Figure 12(c) for administrative control of 
BB_MOD I F I ES ) . If there are no restrictions, the function returns a 
true value. If there are restrictions, the function returns a false 
value . 

Parameters [in] : 
none 

Parameters [out, retval] : 
BOOL* pRet 

Function : CheckBBCancels 

CheckBBCancels operates to return a Boolean value on whether or 
not there are trading restrictions on BB_CANCELS in the trading admin 
database 180 (see Figure 12(c) for administrative control of 
BB_CANCELS) . If there are no restrictions, the function returns a 
true value. If there are restrictions, the function returns a false 
value. 

Parameters [in] : 
none 

Parameters [out, retval]: 
BOOL* pRet 

Function: CheckOptionTrading 

CheckOptionTrading operates to return a Boolean value on 
whether or not there are trading restrictions on OPTION_TRADING in 
the trading admin database 180 (see Figure 12(c) for administrative 
control of O PT I ON_TRAD I NG ) . If there are no restrictions, the 
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function returns a true value. If there are restrictions, the 
function returns a false value. 

Parameters [in] : 

none 

Parameters [out, retval] : 
BOOL* pRet 

Function: CheckOptionModif ies 

CheckOptionModif ies operates to return a Boolean value on 
whether or not there are trading restrictions on OPTION_MODIFIES in 
the trading admin database 180 (see Figure 12 (c) for administrative 
control of OPTION_MODIFIES) . If there are no restrictions, the 
function returns a true value. If there are restrictions, the 
function returns a false value. 

Parameters [in] : 

none 

Parameters [out, retval]: 
BOOL* pRet 

Function : CheckOptionCancels 

CheckOptionCancels operates to return a Boolean value on 
whether or not there are trading restrictions on OPTION__CANCELS in 
the trading admin database 180 (see Figure 12 (c) for administrative 
control of OPTION_CANCELS ) . If there are no restrictions, the 
function returns a true value. If there are restrictions, the 
function returns a false value. 

Parameters [in] : 

none 

Parameters [out, retval] : 
BOOL* pRet 

Function: CheckExtHoursTrading 

CheckExtHoursTrading operates to return a Boolean value on 
whether or not there are trading restrictions on EXT_HOURS_TRADING in 
the trading admin database 180 (see Figure 12(c) for administrative 
control of EXT_HOURS_TRADING) . If there are no restrictions, the 
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function returns a true value . If there are restrictions, the 
function returns a false value. 

Parameters [in] : 

none 

5 Parameters [out, retval]: 
BOOL* pRet 

Function : CheckExtHoursModif ies 

CheckExtHoursModif ies operates to return a Boolean value on 
whether or not there are trading restrictions on EXT_HOURS_MODIFIES 
10 in the trading admin database 180 (see Figure 12(c) for 

administrative control of EXT_HOURS_MODIFIES) . If there are no 
restrictions, the function returns a true value. If there are 
restrictions, the function returns a false value. 

Parameters [in] : 

15 none 

Parameters [out, retval] : 

BOOL* pRet 

Function : CheckExtHoursCancels 

CheckExtHoursCancel operates to return a Boolean value on 
20 whether or not there are trading restrictions on EXT_HOURS_CANCELS in 
the trading admin database 180 (see Figure 12(c) for administrative 
control of EXT_HOURS_CANCELS ) . If there are no restrictions, the 
function returns a true value. If there are restrictions, the 
function returns a false value. 

25 Parameters [in] : 

none 

Parameters [out, retval]: 
BOOL* pRet 

Function: ValidateEquityOrderEntry 

30 ValidateEquityOrderEntry operates to return a Variant array of 

ValidationResults values for several parameters passed into the 
function. The ValidationResults values are determined by creating an 
Equity order and performing a validity check on the action, quantity, 
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symbol, limitPrice, stopPrice, tif, restrictions, tradingPeriod, and 
commission . 

Parameters [in] : 

BSTR customer 

BSTR symbol 

BSTR type 

BSTR action 

BSTR quantity 

BSTR tradeType 

BSTR limitPrice 

BSTR stopPrice 

BSTR tradingPeriod 

BSTR tif 

BSTR restrictions 
BSTR orderSource 

Parameters [out, retval] : 
VARIANT* pResults 

Function: ValidateOptionOrderEntry 

ValidateOptionOrderEntry operates to return a Variant array of 
ValidationResults values for several parameters passed into the 
function. The ValidationResults values are determined by creating an 
Option order and performing a validity check on the action, quantity, 
symbol, limitPrice, stopPrice, tif, restrictions, tradingPeriod, and 
commission. 

Parameters [in] : 

BSTR customer 

BSTR symbol 

BSTR type 

BSTR action 

BSTR quantity 

BSTR tradeType 
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BSTR limitPrice 
BSTR stopPrice 
BSTR tradingPeriod 
BSTR tif 

BSTR restrictions 
BSTR orderSource 

Parameters [out, retval] : 
VARIANT* pResults 

Function : ValidateExtHoursOrderEntry 

ValidateExtHoursOrderEntry operates to return a Variant array 
of ValidationResults values for several parameters passed into the 
function. The ValidationResults values are determined by creating an 
ExtHours order and performing a validity check on the action, 
quantity, symbol., limitPrice, stopPrice, tif, restrictions, 
tradingPeriod, and commission. 

Parameters [in] : 

BSTR customer 

BSTR symbol 

BSTR type 

BSTR action 

BSTR quantity 

BSTR tradeType 

BSTR limitPrice 

BSTR stopPrice 

BSTR tradingPeriod 

BSTR tif 

BSTR restrictions 
BSTR orderSource 



Parameters /out, retval 7 .- 
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VARIANT* pResultS 

Function : ValidateBBOrderEntry 

ValidateBBOrderEntry operates to return a Variant array of 
ValidationResults values for several parameters passed into the 
5 function. The ValidationResults values are determined by creating a 
BB order and performing a validity check on the action, quantity, 
symbol, limitPrice, stopPrice, tif, restrictions, tradingPeriod, and 
commission. 

Parameters [in] : 

10 BSTR customer 

BSTR symbol 

BSTR type 

BSTR action 

BSTR quantity 

15 BSTR tradeType 

BSTR limitPrice 

BSTR stopPrice 

BSTR tradingPeriod 

BSTR tif 

20 BSTR restrictions 

BSTR orderSource 

Parameters [out, retval] : 
VARIANT* pResults 

25 Function: CheckMarketOpen 

CheckMarketOpen operates to determine (1) if it is a market day 
(i.e., not a weekend or a holiday) and (2) whether the market is open 
on that market day. 

Parameters [in] : 

30 none 

Parameters [out, retval]: 

BOOL* pRet 
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Function: CheckExtHoursOpen 

CheckExtHoursOpen operates to determine there is an extended 
trading session. 

Parameters [in] : 

none. 

Parameters [out, retval] : 
BOOL* pRet 

Function: GetFullQuote 

GetFullQuote operates to create a QuoteClient object and 
validates each parameter within that object, then returns a Variant 
array which contains the results of the validation for each 
respective parameter. 

Parameters [in] : 

BSTR symbol 
Parameters [out, retval]: 

VARIANT *pResultS 

Function : OptionLookup 

OptionLookup operates to retrieve a quote for a particular 
option and returns a Variant from the results of the quote. 

Parameters [in] : 

BSTR symbol 
Parameters [out, retval]: 

VARIANT *pResultS 

(Hi) NotificationSwitchClient 

The NotificationSwitchClient object preferably resides on the 
order servers and operates to issue multicast packets containing, 
notifications of the progress of order activity requests. To receive 
notifications, an interested application must preferably subscribe 
for multicasts to the address on the subnet to which the 
NotificationSwitchClient sends its multicasts. 

Each notification is in a similar format to an HTTP 
querystring. Where each name value pair is separated by an ampersand 

(&) and an equal (=) that separates the name and the value. Each 
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notification starts with the type of notification and then an 
ampersand. The following notifications are preferably available: 

Order - an order was placed. ' 

Data: Customer, Action, Quantity, Symbol, Limit Price, Stop 
Price, Account Type, TIF, AON, Trading Period, Commission 

Execution - a trade executed. 

Data: Customer, Action, Quantity, Symbol, Price, Account Type, 
Time, Description, Web Tracking number, Orig Web Tracking 
Number 

Invalidate - general cache invalidation 
Data : Customer 

Cancel - customer placed a cancel request 
Data: Customer, Web Tracking Number 

Modify - customer placed a modify request 
Data: Customer, Web Tracking Number 

Approve an order was approved by the net desk 
Data: Customer, Web Tracking Number 

Reject - an order was rejected by the net desk 

Data: Customer, Web Tracking Number, Reason 

Dequeue - an order was dequeued 

Data: Customer, Web Tracking Number 

U R Out - a cancel request executed 

Data: Customer, Web Tracking Number 

Replaced - a modify request executed 

Data: Customer, Web Tracking Number 

Status - the status of an order changed 

Data: Customer, Web Tracking Number 

The following definitions are used for notifications: 
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Headers 

#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 



NOTIFICATION 
NOTIFICATION 
NOTIFICATION 
NOTIFICATION^ 
NOTIFICATION 
NOTIFICATION 
NOTIFICATION 
NOTIFICATION 
NOTIFICATION 
NOTIFICATION 
NOTIFICATION 
NOTIFICATION 
NOTIFICATION 



ORDER 

EXECTION 

INVALIDATION 

CANCEL 

MODIFY 

APPROVE 

REJECT 

DEQUEUE 

UROUT 

STATUS_CHANGE 
REPLACED 
DELETED 
SYMBOL UPDATE 



"ORDER" 
"EXECUTION" 
" INVALIDATE " 

"CANCEL" 

"MODIFY" 
"APPROVE" 

"REJECT" 
"DEQUEUE" 

"UROUT" 
"STATUS " 
"REPLACED" 
"DELETED" 
"SYM UPDATE" 



Data 

#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 



NOTIFICATION 
NOTIFICATION 
NOTIFICATION 
NOTIFICATION 
NOTIFICATION 
NOTIFICATION 
NOTIFICATION 
NOTIFICATION 
NOTIFICATION 
NOTIFICATION 
NOTIFICATION 

NOTIFICATION 
NOTIFICATION 
NOTIFICATION 
NOTIFICATION 
NOTIFICATION 
NOTIFICATION 
NOTIFICATION 



CUSTOMER 

SYMBOL 

QUANTITY 

LIMIT_PRICE 

STOP_PRICE 

AON • 

TIF 

ACTION 

TRAD ING_PER IOD 

ACCOUNT_TYPE 

PRICE 

TIME 

DESCRIPTION 
COMMISSION 
WEB__TRACKING 
REASON 

OR I G_WEB_TRACKING 
SOURCE 



"CUSTOMER" 

" SYMBOL" 
"QUANTITY" 
"LIMIT_PRICE " 

"STOP_PRICE" 

"AON" 

"TIF" 

"ACTION" 
"TRADING_PERIOD" 
" ACCOUNT_TYPE " 

" PRICE" 

"TIME " 
"DESCRIPTION" 

"COMMISSION" 
"WEBJTRACKING" 

"REASON" 
" ORIG_WEB_TRACKING " 

"SOURCE" " 



Methods 

PostSymbolUpdate 

Event : the security master has been updated for a symbol 



2196964 



- 40 - 



Input : 

BSTR symbol 



PostDelete 
5 Event : a pending order was deleted 
Input : 

BSTR customer 

BSTR webTrackingNumber 

10 PostOrder 

Event : an order was placed 
Input : 

BSTR account 

BSTR action 
15 BSTR quantity 

BSTR symbol 

BSTR limitPrice 

BSTR stopPrice 

BSTR accountType 
20 BSTR tif 

BSTR aon 

BSTR tradingPeriod 
BSTR commission 
BSTR source 

25 

PostExecution 
Event : an order executed 
Input : 

BSTR customer 

30 BSTR action 

BSTR quantity 
BSTR symbol 
BSTR price 
BSTR accountType 

35 BSTR time 

BSTR description 

BSTR webTrackingNumber 

BSTR origWebTrackingNumber 

40 PostCancel 

Event: an order was cancelled 
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Input : 

BSTR customer 

BSTR originalWebTrackingNumber 
BSTR symbol 
5 BSTR source 

PostModify 

Event: an order was modified 
Input : 

10 BSTR customer 

BSTR webTrackingNumber 
BSTR symbol 
BSTR source 

15 PostReject 

Event: an order was rejected by the approval desk 
Input : 

BSTR customer 
BSTR webTrackingNumber 
20 BSTR reason 

Post Approve 

Event: an order was approved by the approval desk 
Input : 

25 BSTR customer 

BSTR webTrackingNumber 

BSTR originalWebTrackingNumber 



30 PostUROUT 

Event: an order was successfully cancelled at the exchange 
Input : 

BSTR customer 

BSTR originalWebTrackingNumber 
35 BSTR symbol 

BSTR time 

PostReplaced 

Event: an order was successfully modified at the exchange 
40 Input : 

BSTR customer 
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BSTR webTrackingNumber 
BSTR time 

Posts tatusChange 
5 Event: an order's status changed in some way 
Input : 

BSTR customer 
BSTR webTrackingNumber 

(iv) Times taunps 

Outgoing orders are preferably times tamped by the order server, 
and the timestamp data is preferably retained in the orders database 
178 before those orders are sent to the exchange. Timestamps are 
also preferably sent to the OMS, where they are again timestamped in 
a text file. Further, the OMS preferably timestamps the ACK on the 
order at the time the OMS sends the receipt response to the. 
OrderServer. This timestamp is logged in a text file. 

When the OMS forwards the order to the exchange 174, the 
exchange 174 ACKS the order and sends the timestamp to the OMS, which 
in turn sends the timestamp to the order servers, where it is saved 
in a text file. 

When the exchange 174 executes the order, it sends a timestamp 
back to the OMS, which forwards it to the order servers. Again the 
timestamp is saved in a text file and is written to the orders 
database 178 with another timestamp. 

This timestamp information is useful for an audit trail of all 
orders . 

B. WBO Service 
30 The Web to Back Office (WBO) service supplies all of the 

accounting information for a customer's account (s) to interested 
applications in the system 150. This customer account data preferably 
includes monies held in the account, what stocks are owned in the 
account, trade executions in the account, open orders (buy, sell, 
35 etc) for the account, and ancillary information such as name, 

address, and so on. This information is often delivered to the 
customer for information on his account (e.g., a "view my portfolio" 
display on the front end customer interface) , but the customer 
account data is also preferably used to determine whether orders for 
40 financial instruments are accepted or rejected. 



10 



15 



20 



25 
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For example, if a customer wishes to sell 100 shares of IBM 
stock, this order activity request is checked to verify the 
customer actually owns 100 shares of IBM . If the customer wishes 
to buy 100 shares of IBM, and IBM is trading at $10 per share, 
this information is used to determine if he has the $1000 in his 
account necessary to carry out this purchase. 

The WBO service can also be used to aggregate data between 
various brokerage accounting systems. For example, if a brokerage 
firm is converting from one back office system to another, and must 
account for trade data information on one system and settlement data 
information on the other (typically three days later) , the WBO 
service can allow for aggregation of data from the two different 
backend database systems . As will be explained in greater detail 
below, as part of this aggregation, a "Three Day System'' was 
developed to facilitate such changes in backoff ice database 
accounting systems, thereby allowing the other services of the system 
to continue seamlessly during a backoffice accounting database 
transition . 

WBO service primarily acquires customer account data from the 
backoffice accounting database system 170, which is preferably an 
AS/400 CRI brokerage accounting system, but can also acquire data 
from .the SQL database schema 166 (such as the customers database 182 
or orders database 178), or other data stores. The WBO service of 
the preferred embodiment of the present invention eliminates the need 
for the front end applications to have to know where customer account 
data resides or in which format it is stored. With WBO Service, 
multiple WBO servers 162 preferably exist behind a TCP/IP load 
balancer 200 to allow for the front end applications to fail over 
seamlessly if any particular WBO server 162 should fail. Preferred 
hardware for the WBO server is a Dell 1550, dual 1133 MHz server with 
1 GB of RAM and mirrored 18 GB drives operating with Microsoft 
Windows 2 000 server. 

The WBOClient.dll is a COM object that communicates with the 
WBOServer application to get account data from the backoffice 
accounting database system 170 using a TCP/IP socket. WBOClient 
preferably resides on both the order servers 160 and the front end 
applications. The WBOClient.dll object is preferably created in the 
C++ language, but can be created under any language that supports 
COM. 

The packets produced and processed by the WBO service are 
preferably formatted in accordance with the protocol described below. 
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However, it should be noted that any protocol suitable for formatting 
messages transmitted between applications is suitable for use with 
the present invention. This protocol is preferably a size- 
delimitated protocol where each X bytes contain a specific piece of 
5 data . 

In operation, the WBO server listens to a port for connections 
from a WBOClient object. When initiated, WBOClient retrieves 
customer account data from the WBOServer application for such things 
that include, but are not limited to account balances, executions, 

10 open orders, positions and account settings. 

The WBOServer program receives the customer account activity 
request from WBOClient as a packet, and creates a generic request 
structure out of the data contained therein. 

Preferably when processing a customer account activity request, 

15 WBOServer searches its resident memory, preferably its application - 
in-memory cache, for any cached data. As will be described in 
greater detail below, customer account data found in cached memory 
that is pertinent to a customer account activity request will be used 
by WBOServer to process the customer account activity request if that 

20 cache data complies with predetermined usage rules. Preferably, 
these usage rules are reconf igurable . In either event, if cached 
data is found and the data is valid according to the cache usage 
rules, then WBOServer sends that cached data back to WBOClient. 

If no cached data can be found or if the cache data does not 

25 comply with the cache usage rules, WBOServer queries the backoff ice 
accounting database system 170 for the data. Upon retrieving the 
appropriate data from the backoff ice accounting database system 170, 
the WBOServer preferably merges this data with data found in the SQL 
databases, e.g. account settings, open orders, specific calculations, 

30 etc. 

WBOServer thereafter preferably performs other calculations 
based on this data to determine more specific account values, and 
then updates its cache record. Lastly, WBOServer preferably returns 
the retrieved customer account data to the client application via the 
35 same socket . 

During the above operation, WBOServer is also listening for 
multicasts from the order servers 160 to know when a client places a 
trade or receives an execution, etc. When an account event occurs in 
a customer account, WBOServer preferably marks any cached data 
40 pertaining to that customer account as invalid, thereby forcing any 
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activity request for information on that account to perform a query 
of fresh data from the backoff ice accounting database system 170. 
Preferred instances of account events will be described below. 

WBOCalculations is a COM object resident on the front end COM 
5 interface that takes account data as parameters and performs 

calculations to determine specific values for an account such as 
buying power, total account value, and market value for account 
positions. Parameters received are data structures representing 
account data such as money balances, open orders, current positions 

10 and current day executions. The logic for these calculations are 
known in the art. As a COM object, WBOCalculations can be used by 
any trading platform that supports COM, thereby facilitating the 
scalability, which allows the system to maintain prompt response 
times despite growing traffic volumes. The WBOCalculations methods 

15 preferably come in two versions, one that takes the "Stream" data in 
byte stream format (e.g. UnsettledReleases) and then another 
variation that takes the array format returned by WBOClient (e.g. 
UnsettledReleasesArr) where each BSTR input parameter can be replaced 
with a VARIANT* . These are as follows : 

20 

UnsettledReleases 

Purpose: Total amount of unsettled sells in the account 
IN 

BSTR moneyBalanceStream 
25 BSTR accountMasterStream 

BSTR openOrderStream 
BSTR executionListStream 
BSTR positionListStream 

OUT 

30 BSTR* pRet 

TodaysExecutions 

Purpose: The total amount in dollars of executions today 
IN 

35 BSTR accountMaster 

BSTR executionList 

unsigned char cAccountType (optional) 

OUT 

BSTR* pRet 

40 

Ge t Op enBuyOrde r Amount 
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Purpose: The total dollar amount of open buy orders in the account 
IN 

BSTR accountMaster 
BSTR openOrderList 
5 BSTR bstrSymbol (optional) 

unsigned char cAccountType (optional) 

OUT 

BSTR* pRet 



10 

CashMarket Value 

Purpose: The total amount of unused cash the account is holding in 
type l (cash) 
IN 

15 BSTR moneyBalanceS t ream 

OUT 

BSTR* pRet 

TradingCash 

20 Purpose: The total amount of available funds for making stock 
purchases for a cash account 
IN 

BSTR moneyBalanceS t ream 
BSTR accountMasterStream 
25 BSTR openOrderStream 

BSTR executionListStream 

OUT 

BSTR* pRet 

30 NetTradeBalance 

Purpose: The total amount of trade date balances in the account (type 
1, 2 and 3) 
IN 

BSTR moneyBalanceStream 
35 BSTR executionListStream 

BSTR positionListStream 

OUT 

BSTR* pRet 



40 NetEquity 
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Purpose : The total amount of trade date balances and market value of 
the positions 
IN 

BSTR moneyBalanceStream 

5 OUT 

BSTR* NetEquity 



MarketValue 

10 Purpose: The total amount of the market value of the positions 
IN 

BSTR moneyBalances 

OUT 

BSTR* pRet 

15 

SettlementBalance 

Purpose: The total amount of settlement date balances in the account 
IN 

BSTR moneyBalanceStream 

20 OUT 

BSTR* pRet 
ShortMarketValue 

Purpose:- The total market value of ali short positions in the account 
25 in 

BSTR moneyBalanceStream 

OUT 

BSTR* pRet 

30 Mar ginMarket Value 

Purpose: The total market value of all positions held in type 2 
(margin) 
IN 

BSTR moneyBalanceStream 

35 OUT 

BSTR* pRet 
TotalAccountValue 

Purpose: The total account value of the account. Positions and free 
40 funds . 

IN 
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BSTR moneyBalanceStream 

OUT 

BSTR* pRet 



5 BuyingPower 

Purpose: Total funds available for purchase for a margin account. 
Does not take out open buy orders . 
IN 

BSTR accountMasterStream 
10 BSTR moneyBalanceStream 

BSTR positionListStream 
BSTR executionListStream 

OUT 

BSTR* pRet 

15 

AvailableBuying Power 

Purpose: Total funds available for purchases for a margin account. 
IN 

BSTR accountMasterStream 
20 BSTR moneyBalanceStream 

BSTR positionListStream 
BSTR executionListStream 
BSTR openOrderStream 

OUT 

25 BSTR* pRet 

Ava i 1 ab 1 eDTBuy ingPowe r 

Purpose: Total funds available for day trade purchases 
IN 

30 BSTR accountMasterStream 

BSTR moneyBalanceStream 
BSTR positionListStream 
BSTR executionListStream 
BSTR openOrderStream 

35 OUT 

BSTR* pRet 



Packets created and processed by the WBO Service are 
formatted such that they contain a Header followed by a ReHeader, 
40 followed by appropriate Request data, followed by a Trailer. 
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The Header contains the following fields with their 
corresponding length: 

Header - 10 bytes 
MessageLength - 6 bytes 
Request - 10 bytes 
Max Reply Size - 6 bytes 
User Reference - 2 0 bytes 
Data Source - 8 bytes 
Protocol - 1 
Reserved - 31 bytes 

The ReHeader contains the following fields with their 
corresponding length: 

Query - 2 0 bytes 

Number of Records - 4 bytes 
Size of each Record - 6 bytes 

The Request section will vary depending on the request 
type, indicated by the Request field of the Header. The Request 
field can have the following values: 



#def ine 


PACKET 


_HEADER_ 


NONE 


"NONE" 


#def ine 


PACKET_ 


_HEADER_ 


ALL 


"ALL" 


#def ine 


PACKET_ 


_HEADER_ 


_POSITIONS 


"POSITIONS" 


#def ine 


PACKET_ 


_HEADER_ 


OPENORDERS 


"OPENORDERS" 


#def ine 


PACKET_ 


HEADER_ 


EXECUTIONS 


"EXECUTIONS" 


#def ine 


PACKET_ 


HEADER^ 


SECURITYJV1ASTER 


"SECMASTER" 


#def ine 


PACKET_ 


HEADER^ 


_ACCOUNT_MASTER 


"ACTMASTER" 


#def ine 


PACKET^ 


_HEADER_ 


_MONE Y_B AliANC E 


"MNYBALANCE" 


#def ine 


PACKET^ 


_HEADER_ 


CALCULATION 


" CALCULATION 


#def ine 


PACKET_ 


_HEADER_ 


_PENDING_TRANSACTIONS 


" PENDINGTRAN 


#def ine 


PACKET_ 


_HEADER_ 


ERROR 


"ERROR" 


#def ine 


PACKET_ 


_HEADER_ 


PING 


"PING" 



The request types for the WBO Service are as follows, the 
functionality of which is readily recognizable to those of ordinary 
skill in the art: 
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"ACTMASTER" 

Account = 8 bytes 

OfficeCode = 3 bytes 

AccountEx = 3 bytes 
5 Taxld =11 bytes 

TradingAuth = 1 bytes 

MarginAgreement = 1 bytes 

OptionAgreement = 1 bytes 

Name = 4 0 bytes 
10 Addressl = 4 0 bytes 

Address2 = 4 0 bytes 

Address3 = 40 bytes 

Email = 71 bytes 

Class = 1 bytes 
15 DayTrader = 1 bytes 

InetTrading = 1 bytes 

Test Group = 1 bytes 

CommissionSchedule = 1 bytes 

AccountRestrictions = 1 bytes 
20 DateOpen = 8 bytes 

Address4 = 4 0 bytes 

AddressS = 40 bytes 

" MN Y B AL AN C E " 

25 TradeDateBall = 14 bytes 

TradeDateMktValuel = 14 bytes 
SettleBall = 14 bytes 
TradeDateBal2 = 14 bytes 
TradeDateMktValue2 = 14 bytes 

30 SettleBal2 = 14 bytes 

TradeDateBal3 = 14 bytes 
TradeDateMktValue3 = 14 bytes 
SettleBal3 = 14 bytes 
TradeDateBal4 = 14 bytes 

35 TradeDateMktValue4 = 14 bytes 
SettleBal4 = 14 bytes 
TradeDateBal5 = 14 bytes 
TradeDateMktValue5 = 14 bytes 
SettleBalS = 14 bytes 

40 TradeDateBal6 = 14 bytes 
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TradeDateMktValue6 = 14 bytes 

SettleBal6 = 14 bytes 

TradeDateBal7 = 14 bytes 

UnsettledOptions = 14 bytes 
5 Unset tledSpecial Funds = 14 bytes 

SnapshotMarketVall = 14 bytes 

SnapshotMarketVal2 = 14 bytes 

SnapshotMarketVal3 = 14 bytes 

UnsettledFunds = 14 bytes 
10 TradeDateMktValue9 = 14 bytes 

UsableSMA = 14 bytes 

MainenanceCall = 14 bytes 

FedCall = 14 bytes 

BuyingPower = 14 bytes 
15 FreeCash = 14 bytes 

StockValue = 14 bytes 

OptiqnValue = 14 bytes 

TradeCount = 6 bytes 

Branchld = 3 bytes 
20 EquityCallAmount = 10 bytes 

DayTradeCall =10 bytes 

SMACharge = 12 bytes 

SMARelease = 12 bytes 

ExtraFreeCash = 14 bytes 
25 SnapshotFreeCash = 14 bytes 

SnapshotTradeBall = 14 bytes 

SnapshotTradeBal2 = 14 bytes 

SnapshotTradeBal3 = 14 bytes 

YesterdayDeposit = 11 bytes 
30 DTMaintenanceExcess = 12 bytes 

DTMaintenanceRequirement = 12 bytes 

DTBODFreeCash = 12 bytes 

DTExecutions = 12 bytes 

SnapShotDate = 8 bytes 

35 

" POSITIONS" 

AccountType = 1 bytes 
Symbol = 6 bytes 
Location = 1; bytes 
40 Description = 42 bytes 
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Shares = 10 
MktValue = 13 bytes 
SecurityType = 1 bytes 
Cusip = 12 bytes 
5 PurchasePrice = 13 bytes 
ScottSymbol = 9 bytes 
TPurch = 11 bytes 
TSale = 11 bytes 
OvernightQuantity = 11 bytes 
10 RestrictedQuantity = 12 bytes 
NewSymbol = 12 bytes 
ClosingOption = 1 bytes 
Trans ferOutQuantity = 12 bytes 
Price = 12 bytes 

15 

"OPENORDERS" 

Ac count Code = 1 bytes 

Symbol = 7 bytes 

WebTrackingNumber = 15 bytes 
20 FixTrackingNumber = 15 bytes 

OriginalWebTrackingNumber = 15 bytes 

Action = 1 bytes 

Quantity = 14 bytes 

StopPrice = 14 bytes 
25 LimitPrice = 14 bytes 

AllOfNone - 1 bytes 

TIF = 1 bytes 

Cusip = 12 bytes 

OrderStatus = 1 bytes 
30 QuantityFilled = 14 bytes 

Quant ityOpen = 14 bytes 

Bid = 14 bytes 

Ask = 14 bytes 

GoodThruDate = 8 bytes 
35 OrderTime = 6 bytes 

ExecDestination = 4 bytes 

DestOverride = 2 7 bytes 

Commission = 14 bytes 

SecurityType = 1 bytes 
40 UnderlyingSymbol = 6 bytes 
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PossibleDuplicate = 1 bytes 
TradingSession = 1 bytes 
OrderType = 1 bytes 
ScottSymbol = 9 bytes 
5 OrderDate = 8 bytes 
Route = 1 bytes 
SenderCompId = 10 bytes 
Comment = 4 0 bytes 
CumQuantity = 13 bytes 
10 Comment2 = 12 5 bytes 
Cancellable = 1 bytes 
Modifiable = 1 bytes 
SecurityClass = 1 bytes 



15 "EXECUTIONS" 

AccountCode = 1 bytes 
BuySellCode = 2 bytes 
TradeDate = 8 bytes 
Symbol = 12 bytes 

20 OrderDate = 8 bytes 
BranchCode = 7 bytes 
SeqNo = 4 bytes 
ExecutionTime = 6 bytes 
Cus i p = 12 by t e s 

25 Quantity = 14 bytes 

Description = 42 bytes 
PriceOffset = 14 bytes 
Commission = 14 bytes 
ExecDestination = 4 bytes 

30 AveragePrice = 14 bytes 
SettlementDate = 8 bytes 
OrderStatusOf f set = 1 bytes 
SecurityClass = 1 bytes 
Con traAc count = 10 bytes 

35 ExecType = 1 bytes 

ScottSymbol = 9 bytes 
SecFee = 8 bytes 
Eamt = 13 bytes 
WebTrackingNumber = 15 bytes 
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"SECYMASTER" 
Cusip = 12 bytes 

Exchange Code = 2 bytes 
5 CType = 1 bytes 

SecClass = 4 bytes 

Elig = 2 bytes 

MarginableFlag = 1 bytes 

PriceDate = 8 bytes 
10 Price = 11 bytes 

UnderlyingCusip = 12 bytes 

UnderlyingSymbol = 6 bytes 

MPV = 5 bytes 

Desc = 52 bytes 
15 ExpMonth = 3 bytes 

Exp Year - 4 bytes 

CallPut = 1 bytes 

StrikePrice = 9 bytes 

Symbol = 6 bytes 
20 MarketCode = 6 bytes 

MarketRank = 6 bytes 

ScottSymbol = 9 bytes 

The Trailer Contains the following fields with their 
25 corresponding length: 

More Flag - 1 byte 

End Of Message - 1 byte 

30 Upon receiving an activity request from WBOClient, WBOServer 

processes the request and returns a response. The response will be 
formatted in the same manner as the request, with the Request field 
containing the correct data for the request type. If the Number of 
Records field of the ReHeader is greater than 1, then Request will 

35 contain the specified number of records. The records will be return 
one after another up to the amount of bytes specified in the Max 
Reply Size of the Header. If not all data can fit in the amount of 
space specified in Max Reply Size then the More Flag of the Trailer 
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will contain a "Y" and WBOClient will follow up with a subsequent 
request to get the rest of the records. 

Miscellaneous field values for the WBO Service are as follows 



// data sources 
#define P ACKE T__HEADER_DATA_FRE SH X F' 
#define PACKET_HEADERJDATA_CACHE % C 

// protocol 

#define PACKET_HEADER__PROTOCOL_ASCII *A' 
#define PACKET_HEADER_PROTOCOL_BINARY *B' 

// error codes 
#define P ACKE T_REQUE S T_T I MEOUT "TIMEOUT" 

#define P ACKE T_REQUE S T__ I NVAL I D "INVALID_REQUEST 

#define PACKET_REQUEST_ERROR_UNKNOWN "UNSPECIFIED" 

const int ClientMaxReplySize = 1400; 

// account types 
tfdefine S COTTRADE_S TR_CASH *0' 

#define S COTTRADE_S TR_MARG IN *l f 

#def ine SCOTTRADE_STR_SHORT y 2' 

#define SCOTTRADE_STR_ACCOUNT_UNKNOWN ■ * 9 ' 

// security classes 

#define S COTTRADE_STR_EQUI TY *0' 

#define SCOTTRADE_STR_OPTION *1' 

#define S COTTRADE_S T R_MUTUAL_ FUND x 2' 

#define SCOTTRADE_STR_UIT *3' 

#define SCOTTRADE_STR_FIXED M ' 

#define S COTTRADE_S TR__TRE AS UR Y '5' 

#define SCOTTRADE_STR_BOND *6' 

#define SCOTTRADE_STR_CD *7 r 

#define SCOTTRADE STR SEC CLASS UNKNOWN y 9' 



// open order secy types 
#define SCOTTRADE_STR_SECY_OPTION 

// call /put 
#define SCOTTRADE STR CALL 
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#define SCOTTRADE_STR_PUT 

# define SCOTTRADE STR CALL NOR PUT 



// B/S 
#define SCOTTRADE 

#define SCOTTRADE 

#define SCOTTRADE 

#define SCOTTRADE 

#define SCOTTRADE 

#define SCOTTRADE 

# define SCOTTRADE 

#define SCOTTRADE 

#define SCOTTRADE 



Codes 
STR_BUY 

STR_SELL 

S TR_S E LL_S HORT 

STR_BUY_TO_COVER 

STR_BUYJTO_OPEN 

STR_BUY_TO_CLOSE 

STR_SELL_TO__OPEN 

STR_SELL_TO_CLOSE 

STR ACTION UNKNOWN 



// TIF Codes 
#define SCOTTRADE_STR_DAY 

#define SCOTTRADE_STR_GTC 

#define SCOTTRADE_STR_TIF_UNKNOWN 

// Status Codes 
#define SCOTTRADE_STR_STATUS_NONE 

#define SCOTTRADE_STR_SENT 

#define SCOTTRADE_STR_ACCEPTED 

#define SCOTTRADE_STR_REJECTED 

#define SCOTTRADE_STR_CANCELLED 

#define SCOTTRADE_STR_PENDING_CANCEL 

#define S COTTRADE_S TR_P END I NG_MOD I FY 

#define S COTTRADE_S TR_MOD I F IED 

idefine S COTTRADE_S TR_S ENT_AND_QUEUED 

// Route Codes 
#define SCOTTRADE_STR_ROUTE_NONE 
#define SCOTTRADE_STR_ROUTE_FIX 
#define SCOTTRADE_STR_ROUTE_QUEUE 
#define SCOTTRADE_STR_ROUTE_APPROVAL 
#define SCOT TRAD E_STR_ROUTE_MANUAL 

// Trading Sessions 
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#define SCOTTRADE_STR_SESSION_REGULAR 0 

#define SCOTTRADE_STR_SESSION_EXT_HOURS 1 

#define SCOTTRADE_STR_SESSION_PREMARKET 2 

// transaction type 

#define SCOTTRADE_STR_ORDER 0 

#define SCOTTRADE_STR_CANCEL 1 

#define S COTTRADE_S TR_MOD I FY 2 

//. option trading auth codes 

#define SCOTTRADE_STR__OPTION_YES % D' 

#define SCOTTRADE_STR_OPTION_COVERED x 2' 

#define SCOTTRADE_STR_OPTION_PROTECTED_PUT '3' 

#define SCOTTRADE_STR_OPTION_SPREAD M' 

#define SCOTTRADE_STR_OPTION_LONG '5' 

#define SCOTTRADE_STR_OPTION_SHORT *6' 

#def ine SCOTTRADE_STR_OPTION_NAKED x 8 ' 

// trading auth 

#define S COTTRADE_S TR_L I M I TED_TRAD I NG M' 

#define SCOTTRADE_STR_FUL,Li_TRADING % K' 

#define SCOTTRADE_STR_OTHER_TRADING % L' 

#define SCOTTRADE_STR_ACCOUNT_ESTABLISHED . *E' 

#define SCOTTRADE_STR_TRAD I NG_AP PROVED *M' 

// account types 

#define SCOTTRADE_STR_IRA '0' 

#define SCOTTRADE_STR_ACCOUNT_CLASS_OTHER *0' 

// risk levels 

#define SCOTTRADE_STR_RISK_SELLS_ONLY U' 

#define SCOTTRADE STR RISK NO TRADING *2' 



// commission schedules 
#def ine SCOTTRADE_STR_COMMISSION_SCHED_SAFEKEEPING 

#def ine SCOTTRADE_STR_COMMISSION_SCHED_TRADITIONAL 
#def ine SCOTTRADE_STR_COMMISSION_SCHED_INTERNET 
#define SCOTTRADE STR COMMISSION SCHED SUPERSAVER 
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// account restrictions 
#define SCOTTRADE_STR_ACCOUNT_RE STRICT I ONS_NONE 

#def ine S COTTRADE_S TR_ACCOUNT_RE STRICT I ONS_SETTLED_FUNDS_ONL,Y 
*1' 

(i) WBOClient Interfaces 

For each record type, there are four interfaces. There will 
be a GetDataStream, GetData, GetDataStreamEx, and GetDataEx, wherein 
"Data" or "DataStream" is a placeholder for the request type. The 
following describes each record type: 

GetDataStream; Returns a byte stream of data for the entire record 
(or recordset) . The data is returned as one continuous character 
array, where each data element is a fixed length delimited field. 

GetDataStreamEx; same as GetDataStream, but allows some extra 
flexibility. It allows the client to determine the source of the 
data, whether it is from cache or if it is from the backoff ice 
accounting database system. 

GetData: The data is returned as an array. In the case of 
recordsets, the array is actually an array of arrays, where each 
element of the master array is an array of data elements. 

GetDataEx: same as GetData, but allows some extra flexibility. It 
allows the client to determine the source of the data, whether it is 
from cache or if it is from the backoff ice accounting database 
system. 

Each "Stream" method for recordsets will preface the data by 
fixed- length delimited information describing the data. This will 
contain the size of each record, and how many records to expect in 
the stream. 

Name Str-Length Str-Offset 
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RecordSize 4 
RecordCount 4 



0 

1 



Immediately after the header, the data will begin. 

It is preferred that internal programming used by the system 
application decide which of the GetDataStream, GetDataStreamEx, 
5 GetData, and GetDataEx is used, the programming being configured in 
accordance with any design choices of the programmer. With the 
present invention, the GetDataStream interface is preferably used. 

A description of the functions supported by WBOClient will 
now be described. 

10 Function: GetPositionStream (recordset) 

This function returns data as an array of elements in the 
same format as the Comm protocol between the WBOServer and WBOClient. 

Parameters [in] : 

BSTR strAccount 

15 Parameters [out,retval] 

VARIANT* pRet (The data is described below) 

Function: GetPositions (recordset) 

Parameters [in] : 

BSTR account 

20 Parameters [out, retval] : 

VARIANT* pRet 

Function : GetPosi t ionsS treamEx ( recordset ) 

This function takes 1 extra parameter that is a boolean 
value which can override the cache on the WBOServer. ' If the value is 
25 true then fresh data is pulled from the backoffice accounting 

database. If the data is false the WBOServer cache is checked and, 
if available, is used. 

Parameters [in] : 

BSTR account 
30 BOOL fresh? 

Parameters [out, retval] : 

VARIANT* pRet 



2196964 



- 60 - 



Function: GetPositionsEx (recordset) 

This function returns data as one long string in the same 
format as the Comm protocol between the WBOServer and WBOClient, 
which the client parses. 

Parameters [in] : 

BSTR account 
BOOL fresh? 

Parameters [out, retval] : 

VARIANT* pRet 

Func t i on : Ge t Ac count Ma s t e r 

This function gets account settings and name and address. 
Returns data as an array of elements in the same format as the Comm 
protocol between the WBOServer and WBOClient. 

Parameters [in] : 

BSTR account 

Parameters [out, retval ] : 

VARIANT* pRet 

Function: GetAccountMasterStream 

This function returns data as an array of elements in the 
same format as the Comm protocol between the WBOServer and WBOClient. 

Parameters [in] : 

BSTR account 

Parameter-s [out, retval] : 

VARIANT* pRet 

Function : GetAccountEx 

Parameters [in] : 

BSTR account 
BOOL fresh? 

Parameters [out, retval]: 

VARIANT* pRet 

Function: GetAccountMasterStreamEx 

This function takes 1 extra parameter that is a boolean 
value which can override the cache on the WBOServer. If the value is 
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true then fresh data is pulled from the backoffice accounting 
database system. If the data is false the WBOServer cache is checked 
and, if available, is used. 



Parameters [in] : 
5 BSTR account 

BOOL fresh? 

Parameters [out, retval] : 

VARIANT* pRet 

Function : GetMoneyBalance 

10 This function gets account balances. It returns data as an 

array of elements in the same format as the Comm protocol between the 
WBOServer and WBOClient. 

Parameters [in] .- 

BSTR account 

15 Parameters [out, retval] : 

VARIANT* pRet 

Function : GetMoneyBalanceStream 

This function returns data as an array of elements in the 
same format as the Comm protocol between the WBOServer and WBOClient. 

20 Parameters [in] : 

BSTR account 

Parameters [out, retval] 

VARIANT* pRet 

Function: GetMoneyBalanceEx 

25 Parameters [in] : 

BSTR account 
BOOL fresh? 

Parameters [out, retval] 

VARIANT* pRet 

30 Function : GetMoneyBalanceStreamEx 

This function takes 1 extra parameter that is a boolean 
value which can override the cache on the WBOServer. If the value is 
true then fresh data is pulled from the backoffice accounting 
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database. If the data is false the WBOServer cache is checked and, 
if available, is used. 

Parameters [in] : 

BSTR account 
BOOL fresh? 

Parameters [out,, retval] 

VARIANT* pRet 

Function GetExecutions (recordset) 

This function gets current day executions for a client. 
Returns data as an array of elements in the same format as the Comm 
protocol between the WBOServer and WBOClient. 

Parameters [in] : 

BSTR account 

Parameters [out, retval] : 

VARIANT* pRet 

Function: GetExecutionStream (recordset) 

This function returns data as an array of elements in the 
same format as the Comm protocol between the WBOServer and WBOClient. 

Parameters [in] : 

BSTR account 

Parameters [out, retval] 

VARIANT* pRet 

Function GetExecutionsEx (recordset) 

This function returns data as one long string in the same 
format as the Comm protocol between the WBOServer and WBOClient, 
which the client parses. 

Parameters [in] : 

BSTR account 
BOOL fresh? 

Parameters [out, retval] : 

VARIANT* pRet 
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Function: GetExecutionStreamEx (recordset) 

This function takes 1 extra parameter that is a boolean 
value which can override the cache on the WBOServer . If the value is 
true then fresh data is pulled from the backoffice accounting 
5 database system. If the data is false the WBOServer cache is checked 
and, if available, is used. 

Parameters [in] : 

BSTR account 
BOOL fresh? 

10 Parameters [out, retval] 

VARIANT* pRet 

Function : GetOpenOrders (recordset) 

This function gets current open orders for a client. It 
returns data as an array of elements in the same format as the Comm 
15 protocol between the WBOServer and WBOClient. 

Parameters [in] : 

BSTR account 

Parameters [out, retval] : 

VARIANT* pRet 

20 Function : GetOpenOrderS tream ( recordset ) 

This function returns data as an array of elements in the 
same format as the Comm protocol between the WBOServer and WBOClient. 

Parameters [in] : 

BSTR account 

25 Parameters [out, retval] 

VARIANT* pRet 

Function: GetOpenOrdersEx (recordset) 

This function returns data as one long string in the same 
format as the Comm protocol between the WBOServer and WBOClient, 
30 which the client parses. 

Parameters [in] : 

BSTR account 
BOOL fresh? 
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Parameters [out, retval] : 

VARIANT* pRet 



Function : GetOpenOrderStreamEx (recordset) 

This function takes 1 extra parameter that is a boolean 
value which can override the cache on the WBOServer. If the value is 
true then fresh data is pulled from the back office accounting 
database system. If the data is false the WBOServer cache is checked 
and, if available, is used. 

Parameters [in] : 

BSTR account 
BOOL fresh? 

Parameters [out, retval] 

VARIANT* pRet 

Function; GetSecurityMaster 

Parameters [in] : 

BSTR symbol 

Parameters [out, retval] : 

VARIANT* pRet 

Function : GetSecurityMasterStream 

This function returns data as an array of elements in the 
same format as the Comm protocol between the WBOServer and WBOClient. 

Parameters [in] : 

BSTR symbol 

Parameter [out, retval ] : 

VARIANT* pRet 

Function : GetSecurityMasterEx 

Parameters [in] : 

BSTR symbol 
BOOL fresh? 

Parameters [out, retval] : 

VARIANT* pRet 
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Function: GetSecurityMasterStreamEx 

This function takes 1 extra parameter that is a boolean 
value which can override the cache on the WBOServer. If the value is 
true then fresh data is pulled from the back office accounting 
5 database system. If the data is false the WBOServer cache is checked 
and, if available, is used. 

Parameters [in] : 

BSTR symbol 
BOOL fresh? 

10 Parameter [out, retval ] : 

VARIANT* pRet 

(ii) WBO Caching 

As noted above, when a WBO server 162 gets a request to 

15 retrieve customer account data, it is preferred that the WBO server 
first check its cache for "fresh" data that has already been 
retrieved from the back office accounting database system 170. By 
maintaining customer account data in its application- in-memory cache, 
the WBO server will reduce the number of times it will need to issue 

20 data requests to the backoffice accounting database system, thereby 
reducing traffic at a potential bottleneck and also increasing 
response time for handling customer account activity requests. 

In order to be considered "fresh", the cached account data 
preferably complies with a plurality of cache usage rules. These 

25 rules, which are preferably directed toward ensuring that the 

customer account data returned by the WBO server is an accurate 
current time reflection of the customer's account, can be programmed 
into the logic of the WBO server. Examples of preferred rules that 
define the conditions under which cached data can or cannot be used 

30 include: (1) for cached data to be used, data for the requested 

customer account must exist in the cache, (2) for cached data to be 
used, the cached data must not have been requested more than a 
predetermined number of times (preferably 30 times) , (3) for cached 
data to be used, the cached data must not have been stored in the 

35 cache for longer than a predetermined duration of time (preferably 5 
minutes) , and (4) for cached data to be used, account events must not 
have occurred in the pertinent customer account since the time that 
the customer account data was cached. 
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Preferably, the WBO servers 162 listen for account events which 
can be communicated thereto via multicasts from other servers . The 
WBO servers can perform this listening task by joining subscription 
lists on a specific multicast IP address and port on the server. An 
5 account event is any event that alters a customer's account. 

Examples of preferred account events include: (1) the placing of an 
order for the pertinent customer account, (2) the placing of a modify 
order for a pertinent customer account, (3) the placing of a cancel 
order for a pertinent customer account, (4) the execution of an order 

10 for a pertinent customer account, (5) approval of an order from the 
approval desk for a pertinent customer account, (6) rejection of an 
order from the approval desk for a pertinent customer account, (7) an 
exchange 174 updating an order for a pertinent customer account 
(preferably coming in through a FixOrderServer multicast) , (8) an 

15 exchange 174 canceling an order for a pertinent customer account, and 
(9) the deletion of a pending order for the pertinent customer 
account . 

Applications preferably create these account events using the 
Notif icationSwitchClient COM object described above. Each 

20 application which may create an account event preferably provides 

methods such as PostOrder, PostExecution, PostModify, and PostCancel 
that takes customer account data as parameters and sends a multicast 
packet to the IP port on which the WBO. servers are listening. 

In the event that cached data is not found or cannot be used 

25 because of the cache usage rules, the WBO server queries the 

backoff ice accounting database system for the customer account data. 
Thereafter, the WBO server queries the orders database 178 and 
customers database 182 for data such as pending orders and specific 
calculations for the account, which are not available from the 

30 backoff ice accounting database system. 

Once it has obtained the requisite customer account data from 
the backoff ice and the orders database, the WBO server merges the 
data into one common dataset and updates its cache with the new data. 
At this time, the "fresh" data timer and "fresh" data request counter 

35 are reset. 

C. Database Schema 

The database schema 166 for the preferred embodiment of the 
present invention preferably is a SQL database schema that uses a 
40 Microsoft SQL Server 2000 to store a variety of information not 

included in the order, WBO, or quote services but still needed to 
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support the various front end applications and the other three 
services . 

As part of the service, the "customers" database 182 contains 
customer account specific information that is not stored on the 
backoff ice accounting database system 170, such as email address, 
trading password, web site preferences, access information such as 
web-site authentication credential, buying power for day-traders, 
exchange agreement signatures, popup messages to be display during 
authentication, address change history, notes, etc. Figure 13 
illustrates a preferred table arrangement for the customers database 
182 . 

Internet customers are preferably added to the customers 
database 182 when a branch manager opens a new account for such 
customers: Non- internet customers are added to the customers 
database 182 through a nightly process in which the data is extracted 
from the back office system 170 and loaded into the customers 
database 182 . An Internet customer is a customer who conducts some 
specified percentage of transactions on his account through the 
Internet. A preferred threshold for Internet customers is one who 
conducts 90% of his account transactions through the Internet . 

The "orders"- database 178 contains orders entered via the 
various front end applications, including orders that may have been 
rejected by the system 150 for various reasons. The orders database 
178 also contains audit trail information on each order such as the 
front end application from which it was entered and the computer 
address from which the order originated. Further, the orders are 
preferably logged by account, symbol, when the order was placed, 
where the order was placed from (internet, IVR, streaming product, 
international trading site, etc) , limit /market , time in force for 
limit orders, and quantity. When orders are executed by the system, 
a corresponding entry is added to an execution table, with details of 
the execution such as account number, total shares for this 
execution, total shares remaining for this transaction, price of 
execution. Figures 14(a) and 14(b) illustrate a preferred table 
arrangement for the orders database 178. 

Every time an order is modified internally or by the customer, an 
audit record is maintained. 

Due to the large amount of data> kept for orders, a copy of all 
data in the orders database is preferably placed on a report server 
nightly. This allows internal users to query the database without 
affecting the customer experience. 
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The "trading admin" database 180 stores non-customer specific 
information required to run the various services, including 
information on the availability for trading of various financial 
instruments, which of the front end applications are available, and * 
5 the status of each service, and other administration and control 
data. The trading admin database 18 0 is also preferably used to 
generate a web tracking number for orders received over the Internet. 
As previously noted, Figures 12 (a) - (c) illustrate various 
administrator interfaces for controlling the trading admin database 

10 180. Figures 15(a) and 15(b) illustrate a preferred table 
arrangement for the trading admin database 180. 

It is preferred that these SQL databases exist in the system in 
a clustered node configuration, as shown in Figure 2, to allow for 
redundancy and fail over. 

15 Whereas most databases are designed as one large database, 

thereby requiring additional hardware be added to the same physical 
box in an effort to keep up with growth requirements, the preferred 
embodiment of the present invention segments the logically grouped 
elements of customers, orders, and trading administration into 

20 distinct databases . Interaction with each of these databases is 

preferred in order to complete a transaction. This partitioning of 
data into separate databases prevents overtaxing of the system, which 
would be a distinct risk under normal database design convention in 
which all of these divisions would have been designed to operate as a 

25 single database. Because the data is already in separate databases 
the system 150 is always ready for scaling. 

Further, by segregating each of the individual components to 
isolated databases, a system administrator is able to place these 
unique databases on a separate physical database servers 166 if 

30 conditions are such that utilization is high. If conditions are such 
that database utilization is low, the system administrator can 
instead use a single database server 166 to host multiple databases. 

D. Quote Service 

35 The quote service preferably utilizes QuoteDB, which is a 

dynamically linked library, to handle communication between client 
applications and QuoteServer, which is an application running on the 
quote server. QuoteDB creates packets to retrieve stock data from 
QuoteServer, parses the response from QuoteServer, and creates data 

40 structures for easy access to the quote data. QuoteClient is 
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preferably a COM wrapper for QuoteDB, thereby rendering the quote 
data accessible through any language that supports COM . 

The quote service preferably supplies real-time and static 
pricing and descriptive information on financial instruments. The 
5 descriptive information preferably includes: last sale, bid, ask, 
volume, and CUSIP, for these instruments. Quote data is typically 
delivered for display to a customer, but is also used to value the 
positions that the customer owns (stocks, bond, options) , and as part 
of the order acceptance process . 
10 For example, if a customer wishes to purchase 100 shares of 

IBM, and has $1000 in his cash account, the ask price for IBM is 
requested and multiplied by the number of shares to determine the 
total cost of the purchase, and if it exceeds the cash in the 
account the order is rejected. 
15 The raw quote data is primarily acquired from market data 

vendors as is known in the art, but can also be acquired from SQL 
databases or other data stores. The QuoteClient/QuoteServer 
combination eliminates the need for the front end applications to 
know where quote data resides or know the format in which the data is 
20 stored. 

Also, through the use of the quote data aggregation technique 
of the preferred embodiment of the present invention, the quote 
service can also fail over between raw quote data sources should a' 
real-time vendor cease to update, consistently providing the 

25 requested data. According to this aspect of the preferred 

embodiment, QuoteServer merges various quote feeds as one generic 
quote source . QuoteServer achieves this by creating connections to 
quote vendors and abstracting their data into a common data format 
used internally by the system 150. Thus, when the quote service 

30 switches to a new quote vendor 172, the quote server will be able to 
appropriately process the raw quote data despite the fact the raw 
quote data from the new vendor may not match the raw quote data from 
the old vendor. For example. Different vendors may use different 
data formatting to describe the same financial instrument. For 

35 example, Berkshire Hathaway Class A stock on the NYSE uses the symbol 
"BRK A". On one vendor, this symbol may be formatted as "BRK.A" 
while on another vendor, that same symbol may be formatted as "BRK- 
A" . With this aspect of the preferred embodiment, the quote server 
abstracts this symbol data to a common data format, thereby rendering 

40 a switch from one quote vendor 172 to another seamless and 
transparent to other services in the system 150. 
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Figures 19 (a) - (f ) illustrate the administrative control 
available with the preferred system 150 over the quote feeds used by 
the quote service. Quote data can be divided into different types, 
including, but not limited to, basic real-time quote data (e.g., last 
5 sale, bid price, ask price, etc.), market depth data (e.g., level 2 

data), fundamental 'data, news, and historical quote data, as is known 
in the art. It may be desirable to use different quote vendors for 
these different types of quote data. Through the preferred system's 
use of a common internal format for quote data, the use of different 

10 quote vendors for different types of quote data is greatly 

facilitated. Figure 19(a) illustrates a summary screen that 
identifies the quote vendor for the different quote data types; ATFI 
being the vendor for quotes, fundamental data, and historical data; 
and no vendors being identified for level 2 data and news. 

15 Figure 19(b) illustrates an administrator interface for 

selecting a quote source. Figure 19(c) illustrates an administrator 
interface for selecting a level 2 source. Figure 19(d) illustrates 
an administrator interface for selecting a fundamentals source. 
Figure 19(e) illustrates an administrator interface for selecting a 

20 news source. Lastly, Figure 19(f) illustrates an administrator 
interface for selecting a history source. 

Also, it is preferable that the quote service cache the quote 
data that it receives from vendors to reduce its need to interact 
with the quote vendors . Reduced quote vendor interaction preferably 

25 translates to prompter response times to quote activity requests. 
Accordingly, the quote server preferably maintains quote data 
obtained from a quote vendor in its resident memory, preferably its 
application- in -memory cache. For quote data maintained in cache to 
be used when processing a quote activity request, it is preferred 

30 that such usage proceed in accordance with usage rules in a similar 
manner described in connection with caching for the WBO service. 
However, with quote data, it is preferred that a different set of 
usage rules be used. With quote data, the most important usage rule 
is preferably time. After a predetermined duration of time, 

35 preferably sixty minutes if the quote service is configured to 

receive uninterrupted and continuous updates on cached quote data 
from the quote vendor, the cached quote data is deemed outdated and 
fresh quote data from the quote vendor will be sought. As should be 
understood, different lengths of time can be used for this time 

40 length. If no updates are being received by the quote server for the 
cached quote data or if there is an interruption in those updates, it 
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can be expected that this freshness time duration wili be 
considerably shorter. 

Further, it is worth noting that the QuoteClient object may 
also be configured to retain quote data it receives for a 
5 predetermined duration of time, preferably around 1 second. 

When receiving a response from the quote vendor, the quote 
server 164 preferably updates its own cache record for future 
requests. QuoteServer also receives quote/trade updates from the 
quote vendor to update it's own cache based on the latest 

10 quote/trade. It is preferred that QuoteServer be capable of merging 
general quote data (last price, bid, ask, volume, etc) , date stored 
in other data stores such as SQL, company fundamental data, stock 
price history, available options, top market movers, real-time 
streaming time and sales and level 2 quote data into one generic 

15 quote source. 

The QuoteClient COM object preferably functions take a 
symbol as the only parameter and return a VARIANT cast as a BSTR. 
Decimal values are returned to three decimal places unless otherwise 
noted. Values are returned as strings and, unless otherwise noted, 
20 functions return "N/A" when data is not available. 

The preferred functions for QuoteClient are as follows: 

AnnualHlgh 

Returns a 52 week high price in fractional format, unless 
quoted in decimals by exchange . 

25 AnnualLow 

Returns a 52 week low price in fractional format, unless quoted 
in decimals by exchange. 

Ask 

Returns the 'ask' as decimal. 

30 AskF 

Returns the ask price in . fractional format, unless quoted in 
decimals by exchange. 

AskSize 

Returns the ask size as an integer. 

35 Bid 

Returns the bid as a decimal . 

BidF 

Returns the bid price in fractional format, unless quoted in 
decimal by exchange . 
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Bid Size 

Returns the bid size as an integer. 
BidTi ck 

Returns for upticks and "-" for downticks. 

5 Change 

Returns net change for the day in decimal format (three decimal 

place precision). If there is no change, return "0". 

ChangeF 

Returns net change for day in a fractional format, unless 
10 quoted in decimals by exchange. If no change, returns "0". 

ChangeF 

Returns net change for day in fractional format, unless quoted 
in decimals by exchange. 

Div 

15 Returns annualized dividend as two decimal dollar/cents value, 

i.e. "$0.48". 

DYield 

Returns annualized dividend yield as two decimal place value, 
i.e. "0.40". If dividend <=0, returns "N/A". 

20 Exchange 

Returns exchange that the last trade occurred on as string. 
Values are OPRA, AMEX, THIRDMARKET, BB, PINK, BOSTON, PACIFIC, 
NASDAQ , NYSE , OTHER . 

FastMarket 

25 • Returns "(F)" if issue is trading in a fast market, 

(space), if not in a fast market or "N/A" if error or symbol is not 
found. 

Font 

Returns <FONT COLOR="red"> if net change is negative, <FONT 
30 COLOR="green"> if change is positive, <FONT C0L0R="black"> if change 
is 0. Note: you must close tag (</FONT>) . 

Returns a w " (space), if there is an error. 

Get First 

Returns the first equity in the database. 

35 GetFirstlndex 

Returns the first index in database. 

GetNext 

Passes an equity symbol and returns the next in the database. 
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Ge tNex t Index 

Passes an index symbol and returns the next in the database. 

Halted 

Returns "(H)" if issue has been halted from trading, " " 
5 (space) if not halted or "N/A" if error or symbol is not found. 

High 

Returns the high for day in decimal format. 

HighF 

Returns the high for day in fractional format, unless quoted in 
10 decimals by exchange. 

Low 

Returns the low for day in decimal format. 

LowF 

Returns the low for day in fractional format, unless quoted in 
15 decimals by exchange. 

Market 

Returns the prime exchange of this issue. Values are: CBOE, 
CINC, AMEX, CHX, BSE, NYSE, PCX, PHLX, NASDAQ Funds, NASDAQ NMS , 
NASDAQ Third Market, NASDAQ OTC BB, NASDAQ Small Cap, NASDAQ OTC . 

20 Name 

Returns the company name as string up to 36 characters. 

Open 

Returns the open in decimal format . 

OpenF 

25 Returns the open price in fractional format, unless quoted in 

decimals by exchange . 

Op tl onDel i verabl eDesc 

Returns a description of deliverable, i.e. "One contract of 
this option represents 100 shares of MS FT . The contract size is 100." 
30 or "One contract of this option represents 94 shares of CPQ plus 
$3014 cash. The contract size is 100. " "ERROR" is returned if a 
description is not found. 

Op t i onDel i verabl ePri ced 

Returns the synthetic price of the deliverable for an option as 
35 a decimal. If complex underlying, builds the price based on weights 
of the underlyings and cash deliverables. This is multiplied by 
contract size to get the total value of deliverable. 

Op t i onFromSh or t 
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Returns a description of the option for a given option symbol, 
i.e., "MS FT JULY 1999 75.000 PUT". If the description is not found, 
or the symbol is invalid, "ERROR" is returned. 

Op ti onLookup 

5 If found, returns the option symbol (String under lyingSymbol , 

int f ourDigitYear , int month (1-12), float strikePrice, bool isCall, 
otherwise returns a blank string. 

Options tandard 

Returns "TRUE" if option is not complex, and shares per 
10 contract are equal to contract size. Otherwise returns "FALSE". 
ERROR" returned if option not found. 

PClose 

Returns the previous close in decimal format. 
PCloseF 

15 Returns the previous close as fraction, unless quoted in 

decimals by exchange. 

Sale 

Returns the last trade price in decimal format . 

SaleF 

20 Returns the last trade price in fractional format, unless 

quoted in decimals by exchange . 

SaleSize 

Returns the size of the last sale in integer format. 

Tick 

25 Returns " + ", if the last sale tick is ah uptick, and "-" if it 

is a downtick. 

Tim 

Returns the time of the last sale in hh:mm format. 
UP\ C11830 

30 Returns "®" if issue is UPC 11830 restricted, " " (space) if 

not restricted and "N/A" if an error occurs or the symbol is not 
found . 

Volume 

Returns the total daily volume as an integer. 

35 Also listed below is fundamental, non-real time data about 

a financial instrument that is typically used for research display 
purposes . 
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Standard 

-Description 

-IndustrySICl 

-IndustrySIC2 
5 - Indus trySIC3 

-IndustrySIC4 

- Sec torMarkGuide 

- IndustryMarkGuide 

-NumlnstHoldingShares 
10 -PercentHeldlnstitutions 

-SharesOut standing 

- Da teSymbol Change 

- Previous Symbol 

- FortuneNumber 
15 -Shareholders 

-Employees 

- PrimarkNumber 

-Cusip 

Balance Sheet 

20 -ReportDate Income 
-ReportDateBalance 
-ReportDateCash 
-RevenueSales 
-GrossProf its 

25 -Net Income 

- CurrentAssets 
-LongTermlnvestments 
-Total Assets 
-CurrentLiabilities 

30 -LongTermDebt 
- Capitals tock 
-RetainedEarnings 
-TotalCashFromOperating 
-TotalCashFromlnvesting 

35 -NetChangelnCash 

Calculated 

- Annua 1 H i ghDa t e 

- Annua 1 LowDa t e 

- Moving Ave rage 9Day 
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-MovingAveragel4Day 
-MovingAverage2 IDay 
-MovingAverageSODay 
-MovingAveragelOODay 
5 - Mo vingAve rage 2 0 ODay 
-ClosePriceWeek 
-ClosePriceMonth 
-ClosePriceQuarter 
-ClosePriceYear 
10 -AverageVolume22Day 
- Ave rag e Vo 1 ume 1 0 0 Day 
-Volatility2 0Day 
-Volatility6Month 

Earnings 

15 -EarningsFiscalYearEnd 
-Lastl2MonthEPSFootnote 
-LastFiscalYearEPSFootnote 
-Lastl2MonthEPS 
-Previousl2MonthEPS 

20 -Last Fiscal YearEPS 

-PreviousFiscalYearEPS 

-LastQuarterEPS 

- PreviousQuarterEPS 

-EstimatedReportDate 

25 -NumberReportingBrokers 

-CurrentQuarterEstimatedEPS 
-NextQuarterEstimatedEPS 
- Current YearEstimatedEPS 
-NextYearEstimatedEPS 

30 Dividend 

- IndicatedAnnualDiv 
- IndicatedAnnualDivNotes 
- PrevCashDivDate 
-NextDivDatel 
35 -NextDivDate2 
-NextDivDate3 
-NextDivDate4 
-SpecialDivDate 
- Nex t Di vAmount 1 
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-NextDivAmount2 
- NextDi vAmoun 1 3 
-NextDivAmount4 
-SpecialDivAmount 
5 -SpecialDivNotes 
-CashDivPayDate 
-CashDivRecordDate 
-CashDivDeclareDate 
-DividendComment 

Calculated Historical 

-VolatilitylMonth 
-Volatility2Month 
-Volatility3Month 
-Volatility4Month 
-Volatility5Month 
-Volatility6Month 
-Volatility7Month 
-Volatility8Month 
-Volatility9Month 
-VolatilitylOMonth 
-VolatilityllMonth 
-Volatilityl2Month 

Split 

-SplitRatio 
-SplitExDate 
-SplitSharesAf ter 
-SplitSharesBef ore 
-SplitDeclareDate 
- Spl i tRecordDat e 
-SplitPaymentDate 
-Split Comment 

MISC 

- ForwardPERat io 
-TrailingPERatio 
35 -MarketCap 

III. BACK END LAYER: 



10 



15 



20 



25 



30 
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The backend layer 156 of the preferred embodiment of the 
present invention includes a data repository such as a backoffice 
accounting database system 170, a quote data source 172, and an 
order management system (OMS) 168 that provides access to any 
5 trading market that will accept automated orders related to 

financial instruments . Examples of acceptable trading markets 
include the NYSE, Nasdaq, AMEX, and others. 

Design and use of such systems is well-known in the art. As 
such, they will not be greatly elaborated on herein. A preferred 

10 backoffice accounting database system 170 is a CRI system that is 

known in the art. Further, numerous quote vendors exist in the field 
from which quote data is available . 

The Order Management System (OMS) 168, is the ^traffic police' 
between the system's order service, the backoffice accounting 

15 database system 170, and the various stock exchanges and execution 

points (market centers) to which financial institution sends orders. 
The OMS 168 accepts orders from the various customer front end 
delivery channels via the order service as well as 'green screen' 
orders that are manually entered by a financial institution's brokers 

20 from the backoffice accounting database system 170. 

As is known in the art, and not part of the invention herein, 
the OMS performs various functions on the order before sending it the 
exchange . While various order management systems can be used in 
connection with the present invention, the OMS used in the preferred 

25 embodiment herein is an Integrate and Intel liroute manufactured by 
IBSN, Inc. of Denver, CO.. - 

Orders from the order servers are copied by the OMS 168, and 
the copy is sent to the backoffice accounting database 170. Since a 
copy of orders that originate from the backoffice accounting database 

30 170 are already stored in the backoffice accounting database 170, a 
copy of those order from the OMS 16 8 is not required. 

During market hours, an order being processed by the OMS 16 8 
is passed through various routing functions that determine the market 
center to which the order is to be delivered. This routing depends 
35 on a number of parameters such as: NASDAQ or NYSE stock, size of the 
order, destination of the original order if this order is a change or 
cancellation of an earlier order, status of the execution point, etc. 
As noted above, the OMS 168 performs these tasks using known 
techniques. 



2196964 - 79 - 



The OMS 16 8 sends this order to the appropriate market 174 
using a financial industry standard protocol known as "FIX", which is 
an order message format enclosed in TCP/IP communications protocol 
for transmission via data lines to the market centers. 

5 If the financial markets are not open, the order is queued 

by the OMS 168 in a local data store where it awaits transmission to 
the financial markets once those markets are open to accept orders. 

The OMS 168 also receives notifications of order execution, 
cancellation and reject messages from the market centers in response 
10 to orders sent thereto. These messages are passed to both the 
backoff ice accounting database 170 and the Orders service. The 
backoffice accounting database 170 uses this information to update 
the customer's accounts. The Orders service provides this 
information to interested applications (such as the front end client 
. 15 application that initiated the order) via the Notif icationSwitch 
multicast . 

Figure 17 illustrates the flexibility of the system 150 to 
accommodate changes in the back end layer 156. For example, multiple 
order management systems 168a and 168b can be used transparently by 

20 the intermediate layer 154. Also, as noted above, multiple quote 
vendors 172a and 172b can be transparently used. A particular 
advantage of the system 150 is that it lends itself to efficient 
changes in the backoffice accounting database system 170. 

In the past, changes in a backoffice accounting database system 

25 170, while keeping the trading system online, have created major 
difficulties because of the traditional 3 day delay between an 
order's trade data and settlement date, and because of option trades. 
That is, during the first three days of a migration from an old 
database system 17 0a to a new database system 170b, the new database 

30 system 170b would not have an accurate picture of *the customer's 
account due to the settlement dates still pending. In previous 
efforts known to the inventors herein, efforts to migrate from one 
backoffice system 170a to another 170b have entailed data entry 
personnel manually keying orders during the first three days of 

35 transition into both the old and new system. 

However, with the intermediate layer 152 of system 150, 
efficient migration can be achieved using a "three day system" as 
described herein. When implementing the "three day" system, the 
timeline for operations is based on the settlement period of equity 

40 trades. At the current time, the standard settlement period for 
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equity trades is three days. The standard settlement period for 
option trades is one day. It should be noted that these settlement 
periods may change in the future. However, the principles of the 
"three day" system are equally applicable for database migrations 
5 when the settlement periods are longer or shorter so long as 

corresponding changes are made in the pertinent time intervals which 
will be discussed below. 

Prior to the database migration, the new backoff ice system is 
preferably minimally populated with only customer name and address 

10 information. The old backoff ice system, as would be expected, is 
populated with full customer account information. 

During a first time interval that commences when the new 
backoff ice system goes live and concludes two days thereafter, data 
relating to option trades that are transacted by the automated 

15 brokerage system during this time interval are stored in the old 

backoff ice system. Further, during this time interval, data relating 
to equity trades that are transacted by the automated brokerage 
system during this time interval are stored in the new backoff ice 
system. For activity requests received during this time interval 

20 that require customer account data, the WBO servers preferably 

retrieve customer account data from both the old and new backoff ice 
systems and aggregate this retrieved data to obtain a full and 
accurate picture of a customer's account. Option trades that arise 
during this interval are stored in the old backoff ice system because 

25 their settlements will occur within the three day window. However, 

because the settlement of new equity trades will fall after the three 
day window, that data is stored in the new backoff ice system that 
will remain live at the conclusion of the three days. 

Upon the conclusion of the first time interval, the second time 

30 interval begins . The duration of the second time interval is 

preferably one day given the three day settlement period for equity 
trades. During this second time interval, data relating to both 
option trades and equity trades that have been transacted by the 
automated brokerage system during the second time interval are stored 

35 in the new backoff ice system. Further, for activity requests 

received during this second time interval that require customer 
account data, the WBO servers preferably continue to retrieve 
customer account data from both the old and new backoff ice systems 
and aggregate this retrieved data to obtain a full and accurate 

40 picture of a customer's account. 
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At the conclusion of the second time interval (which, as noted, 
is preferably three days after the new backoffice system has gone 
live) , the old backoffice system will no longer have active 
settlement dates pending for either equities or options. The content 
5 of the old backoffice system can then be copied into the new 
backoffice system. 

It is preferred that the three day system commence on a 
Wednesday such that it will conclude at close of business on a 
Friday, thereby allowing the copying of the old backoffice system 
10 into the new backoffice system to occur during a time period where 

the markets are not open. Even more preferably, the three day window 
of the "three day" system will expire at the close of business Friday 
prior to a three day weekend or holiday weekend. However, other days 
of the week may also be chosen as would be understood by those of 
15 ordinary skill in the art. 

While the present invention has been described above in 
relation to its preferred embodiment, various modifications may be 
made thereto that still fall within the invention's scope, as would 
be recognized by those of ordinary skill in the art. Such 
20 modifications to the invention will be recognizable upon review of 
the teachings herein. For example, it should be readily understood 
that the various services can be geographically remote from each 
other. Further, the system 150 can be duplicated at multiple 
geographic locations, such as shown in Figure 18 wherein routers 300a 
25 and 3 00b are used to provide a connection to the backoffice from a 
site remote from the backoffice. As such, the full scope of the 
present invention is to be defined solely by the appended claims and 
their legal equivalents . 
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